From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "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: | 2021-06-16 15:41:42 |
Message-ID: | CAM-w4HO_zT=4ET6ByEnG_XP6n7DH=M937YYfUPiHPTg1ej0Qug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-06-16 15:52:45 | Re: [bug?] Missed parallel safety checks, and wrong parallel safety |
Previous Message | Ha Ka | 2021-06-16 15:15:04 | Re: Unresolved repliaction hang and stop problem. |