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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: snapshot too old issues, first around wraparound and then more.
Дата
Msg-id 709179.1623859257@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: snapshot too old issues, first around wraparound and then more.  (Greg Stark <stark@mit.edu>)
Ответы Re: snapshot too old issues, first around wraparound and then more.  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> 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.

I agree that's a great use-case.  I don't like this implementation though.
I think if you want to set things up like that, you should draw a line
between the tables it's okay for the long transaction to touch and those
it isn't, and then any access to the latter should predictably draw an
error.  I really do not like the idea that it might work anyway, because
then if you accidentally break the rule, you have an application that just
fails randomly ... probably only on the days when the boss wants that
report *now* not later.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Yugo NAGATA
Дата:
Сообщение: Re: pgbench bug candidate: negative "initial connection time"
Следующее
От: Robert Haas
Дата:
Сообщение: Re: a path towards replacing GEQO with something better