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

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>, Greg Stark <stark@mit.edu>, Noah Misch <noah@leadboat.com>, Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Kevin Grittner <kgrittn@gmail.com>
Date: 2021-06-16T19:06:37Z
Lists: pgsql-hackers
Hi,

On 2021-06-16 10:44:49 -0700, Peter Geoghegan wrote:
> On Wed, Jun 16, 2021 at 10:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Of course, there's still the question of how VACUUM could cheaply
> > apply such info to decide what could be purged.

> I would think that it wouldn't really matter inside VACUUM -- it would
> only really need to be either an opportunistic pruning or an
> opportunistic index deletion thing -- probably both. Most of the time
> VACUUM doesn't seem to end up doing most of the work of removing
> garbage versions. It's mostly useful for "floating garbage", to use
> the proper GC memory management term.

I don't fully agree with this. For one, there are workloads where VACUUM
removes the bulk of the dead tuples. For another, slowing down VACUUM
can cause a slew of follow-on problems, so being careful to not
introduce new bottlenecks is important. And I don't think just doing
this optimization as part of on-access pruning is reasonable
solution. And it's not like making on-access pruning slower is
unproblematic either.

But as I said nearby, I think the hardest part is figuring out how to
deal with ctid chains, not the efficiency of the xid->visibility lookup
(or the collection of data necessary for that lookup).

Greetings,

Andres Freund



Commits

  1. Remove the "snapshot too old" feature.

  2. Improve timeout.c's handling of repeated timeout set/cancel.

  3. Fix two bugs in MaintainOldSnapshotTimeMapping.