Re: snapshot too old issues, first around wraparound and then more.
Greg Stark <stark@mit.edu>
From: Greg Stark <stark@mit.edu>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Noah Misch <noah@leadboat.com>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, Andres Freund <andres@anarazel.de>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Kevin Grittner <kgrittn@gmail.com>
Date: 2021-06-16T15:41:42Z
Lists: pgsql-hackers
I think Andres's point earlier is the one that stands out the most for me: > I still think that's the most reasonable course. I actually like the > feature, but I don't think a better implementation of it would share > much if any of the current infrastructure. That makes me wonder whether ripping the code out early in the v15 cycle wouldn't be a better choice. It would make it easier for someone to start work on a new implementation. There is the risk that the code would still be out and no new implementation would have appeared by the release of v15 but it sounds like that's people are leaning towards ripping it out at that point anyways. Fwiw I too think the basic idea of the feature is actually awesome. There are tons of use cases where you might have one long-lived transaction working on a dedicated table (or even a schema) that will never look at the rapidly mutating tables in another schema and never trigger the error even though those tables have been vacuumed many times over during its run-time.
Commits
-
Remove the "snapshot too old" feature.
- f691f5b80a85 17.0 landed
-
Improve timeout.c's handling of repeated timeout set/cancel.
- 09cf1d522676 14.0 cited
-
Fix two bugs in MaintainOldSnapshotTimeMapping.
- 55b7e2f4d78d 14.0 cited