Re: snapshot too old issues, first around wraparound and then more. - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: snapshot too old issues, first around wraparound and then more.
Date
Msg-id CA+hUKGKDcKgVfgHQ+NXVqumd76PcAQp-SGM5ypvNj36yccAnFw@mail.gmail.com
Whole thread Raw
In response to Re: snapshot too old issues, first around wraparound and then more.  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: snapshot too old issues, first around wraparound and then more.  (Andres Freund <andres@anarazel.de>)
Re: snapshot too old issues, first around wraparound and then more.  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Fri, Apr 3, 2020 at 2:22 PM Peter Geoghegan <pg@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.



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: pg_basebackup, manifests and backends older than ~12
Next
From: Michael Paquier
Date:
Subject: Re: backup manifests