Re: pgsql: Track the current XID wrap limit (or more accurately, the oldest

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: Track the current XID wrap limit (or more accurately, the oldest
Дата
Msg-id 1558.1251749840@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql: Track the current XID wrap limit (or more accurately, the oldest  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-committers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> 1. Cluster is close to the stop limit.
> 2. Autovacuum runs, updates pg_database and advances oldestXid. Phew!
> 3. Crash.

> After recovery, oldestXid is reset to the old value, and you start
> getting warnings again. However, everything seems fine in pg_database,
> all the databases have been recently vacuumed. Does autovacuum ever run
> to fix that? ISTM it won't.

Autovacuum will certainly run, it's more a question of will it fix
oldestXid.  I think we could deal with this by having the just-added
function TransactionIdLimitIsValid() return false if the oldestXid is
far enough back to cause warnings.

(Probably that wasn't the best choice of name, since we now have some
cases where the XID limit data isn't really "invalid" but we want to
force an update anyway.  I'm inclined to rename it to something like
ForceTransactionIdLimitUpdate, with inversion of the result sense.)

            regards, tom lane

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

Предыдущее
От: tgl@postgresql.org (Tom Lane)
Дата:
Сообщение: pgsql: Change the autovacuum launcher to read pg_database directly,
Следующее
От: tgl@postgresql.org (Tom Lane)
Дата:
Сообщение: pgsql: Move processing of startup-packet switches and GUC settings into