Hi, On 2020-04-13 14:58:34 +1200, Thomas Munro wrote: > On Fri, Apr 3, 2020 at 2:22 PM Peter Geoghegan <p...@bowt.ie> wrote: > > I think that it's worth considering whether or not there are a > > significant number of "snapshot too old" users that rarely or never > > rely on old snapshots used by new queries. Kevin said that this > > happens "in some cases", but how many cases? Might it be that many > > "snapshot too old" users could get by with a version of the feature > > that makes the most conservative possible assumptions, totally giving > > up on the idea of differentiating which blocks are truly safe to > > access with an "old" snapshot? (In other words, one that assumes that > > they're *all* unsafe for an "old" snapshot.) > > > > I'm thinking of a version of "snapshot too old" that amounts to a > > statement timeout that gets applied for xmin horizon type purposes in > > the conventional way, while only showing an error to the client if and > > when they access literally any buffer (though not when the relation is > > a system catalog). Is it possible that something along those lines is > > appreciably better than nothing to users? If it is, and if we can find > > a way to manage the transition, then maybe we could tolerate > > supporting this greatly simplified implementation of "snapshot too > > old". > > Hi Peter, > > Interesting idea. I'm keen to try prototyping it to see how well it > works out it practice. Let me know soon if you already have designs > on that and I'll get out of your way, otherwise I'll give it a try and > share what I come up with.
FWIW, I think the part that is currently harder to fix is the time->xmin mapping and some related pieces. Second comes the test infrastructure. Compared to those, adding additional checks for old snapshots wouldn't be too hard - although I'd argue that the approach of sprinkling these tests everywhere isn't that scalable... Greetings, Andres Freund
