RE: Temporary tables prevent autovacuum, leading to XID wraparound
Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>
From: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
To: 'Robert Haas' <robertmhaas@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-01-31T00:04:32Z
Lists: pgsql-hackers
From: Robert Haas [mailto:robertmhaas@gmail.com] > Unfortunately, I think a full solution to the problem of allocating AV > workers to avoid wraparound is quite complex. Yes, that easily puts my small brain into an infinite loop... > Given all of the foregoing this seems like a very hard problem. I can't > even articulate a clear set of rules for what our priorities should be, > and it seems that such rules would depend on the rate at which we're consuming > XIDs, how close we are in each database to a wraparound shutdown, what tables > exist in each database, how big the not-all-frozen part of each one is, > how big their indexes are, how much they're holding back relfrozenxid, and > which ones already have workers, among other things. I think it's quite > possible that we can come up with something that's better than what we have > now without embarking on a huge project, but it's not going to be anywhere > near perfect because this is really complicated, and there's a real risk > that we'll just making some cases better and others worse rather than > actually coming out ahead overall. So a simple improvement would be to assign workers fairly to databases facing a wraparound risk, as Sawada-san suggested. One ultimate solution should be the undo-based MVCC that makes vacuuming unnecessary, which you proposed about a year ago... Regards Takayuki Tsunakawa
Commits
-
Clarify comment about assignment and reset of temp namespace ID in MyProc
- 9fc9933695af 11.0 landed
- 1339fcc89617 12.0 landed
-
Make autovacuum more aggressive to remove orphaned temp tables
- 943576bddcb5 11.0 landed
- 246a6c8f7b23 12.0 landed
-
Don't count background workers against a user's connection limit.
- 13752743bf70 9.6.2 cited