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

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: snapshot too old issues, first around wraparound and then more.
Дата
Msg-id CAM-w4HO_zT=4ET6ByEnG_XP6n7DH=M937YYfUPiHPTg1ej0Qug@mail.gmail.com
обсуждение исходный текст
Ответ на Re: snapshot too old issues, first around wraparound and then more.  (Peter Geoghegan <pg@bowt.ie>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Ha Ka
Дата:
Сообщение: Re: Unresolved repliaction hang and stop problem.
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [bug?] Missed parallel safety checks, and wrong parallel safety