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
-
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