Re: snapshot too old issues, first around wraparound and then more.

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Kevin Grittner <kgrittn(at)gmail(dot)com>
Subject: Re: snapshot too old issues, first around wraparound and then more.
Date: 2020-04-13 02:58:34
Message-ID: CA+hUKGKDcKgVfgHQ+NXVqumd76PcAQp-SGM5ypvNj36yccAnFw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 3, 2020 at 2:22 PM Peter Geoghegan <pg(at)bowt(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-04-13 03:25:01 Re: backup manifests
Previous Message Kyotaro Horiguchi 2020-04-13 02:52:51 Re: pg_basebackup, manifests and backends older than ~12