regarding bloat and fragmentation, if it's ensured that the long-running tx can access to only the table A, we can safely vacuum table B even while that tx is running? #pgconfasia
-
-
Replying to @fujii_masao
In theory, yes -- but we have no mechanism to prevent the long-running tx from accessing new tables. For example, suppose a PL/pgsql function tricky(int) is called. When $1 < 10000000, it accesses table A; else table B. So a new table could be accessed quite late.
1 reply 0 retweets 1 like -
Replying to @robertmhaas
yes, and I was thinking to prepare such a mechanism when I was involved in the system having long-running batch transaction. that didn't happen because it was successfully divided to several tx, though.
1 reply 0 retweets 0 likes -
Replying to @fujii_masao
I think it's quite a hard problem. I think you could have a PGPROC flag indicating that the transaction is prohibited from locking any new tables; if the flag is set, then query the lock manager to see which tables it already has locked. Might be expensive, though.
2 replies 0 retweets 0 likes -
Replying to @robertmhaas @fujii_masao
I think it'd be more promising to start vacuuming rows that are newer than the longrunning transaction, but already deleted. That'd not require the restriction of not accessing new tables in old transaction, which I don't see us exposing to SQL.
2 replies 0 retweets 0 likes -
We could also track longest running transaction per database
1 reply 0 retweets 0 likes -
I'm not seeing how that's related to the discussion?
2 replies 0 retweets 0 likes -
Fujii didn't specifically say table B was in the same database as table A... But yeah I know it probably was :)
1 reply 0 retweets 0 likes
We filter out longrunning transactions on other databases for the purpose of vacuuming. CF GetOldestXmin().
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.