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

From Greg Stark
Subject Re: snapshot too old issues, first around wraparound and then more.
Date
Msg-id CAM-w4HO_zT=4ET6ByEnG_XP6n7DH=M937YYfUPiHPTg1ej0Qug@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.  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: snapshot too old issues, first around wraparound and then more.  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
I think Andres's point earlier is the one that stands out the most for me:

> I still think that's the most reasonable course. I actually like the
> feature, but I don't think a better implementation of it would share
> much if any of the current infrastructure.

That makes me wonder whether ripping the code out early in the v15
cycle wouldn't be a better choice. It would make it easier for someone
to start work on a new implementation.

There is the risk that the code would still be out and no new
implementation would have appeared by the release of v15 but it sounds
like that's people are leaning towards ripping it out at that point
anyways.

Fwiw I too think the basic idea of the feature is actually awesome.
There are tons of use cases where you might have one long-lived
transaction working on a dedicated table (or even a schema) that will
never look at the rapidly mutating tables in another schema and never
trigger the error even though those tables have been vacuumed many
times over during its run-time.



pgsql-hackers by date:

Previous
From: Ha Ka
Date:
Subject: Re: Unresolved repliaction hang and stop problem.
Next
From: Robert Haas
Date:
Subject: Re: [bug?] Missed parallel safety checks, and wrong parallel safety