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

Peter Geoghegan <pg@bowt.ie>

From: Peter Geoghegan <pg@bowt.ie>
To: Noah Misch <noah@leadboat.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, Andres Freund <andres@anarazel.de>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Kevin Grittner <kgrittn@gmail.com>
Date: 2021-06-16T06:48:47Z
Lists: pgsql-hackers
On Tue, Jun 15, 2021 at 11:24 PM Noah Misch <noah@leadboat.com> wrote:
> When I say "some hackers", I don't mean that specific people think such
> thoughts right now.  I'm saying that the expected cost of future cooperation
> with the feature is nonzero, and bugs in the feature raise that cost.

I see.

> > > A hacker adopting the feature would be aiming to reduce (2)(b) to zero,
> > > essentially.  What other interests are relevant?
> >
> > The code simply isn't up to snuff. If the code was in a niche contrib
> > module then maybe it would be okay to let this slide. But the fact is
> > that it touches critical parts of the system. This cannot be allowed
> > to drag on forever. It's as simple as that.
>
> Even if we were to stipulate that this feature "isn't up to snuff", purging
> PostgreSQL of substandard features may or may not add sufficient value to
> compensate for (1) and (4).

I'm more concerned about 1 (compatibility) than about 4 (perception
that we deprecate things when we shouldn't), FWIW.

It's not that this is a substandard feature in the same way that (say)
contrib/ISN is a substandard feature -- it's not about the quality
level per se. Nor is it the absolute number of bugs. The real issue is
that this is a substandard feature that affects crucial areas of the
system. Strategically important things that we really cannot afford to
break.

-- 
Peter Geoghegan



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.