Re: Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Cluster "stuck" in "not accepting commands to avoid wraparound data loss"
Дата
Msg-id CA+TgmoZSF=gq_TVuMpvtAxEDRSLaz+VZC3CX3ASutc6+gCh7Qg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Cluster "stuck" in "not accepting commands to avoid wraparound data loss"  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
On Fri, Dec 11, 2015 at 1:08 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> Since changes to datfrozenxid are WAL logged at the time they occur,
> but the supposedly-synchronous change to ShmemVariableCache is not WAL
> logged until the next checkpoint, a well timed crash can leave you in
> the state where the system is in a tizzy about wraparound but each
> database says "Nope, not me".

ShmemVariableCache is an in-memory data structure, so it's going to
get blown away and rebuilt on a crash.  But I guess it gets rebuild
from the contents of the most recent checkpoint record, so that
doesn't actually help.  However, I wonder if it would be safe to for
the autovacuum launcher to calculate an updated value and call
SetTransactionIdLimit() to update ShmemVariableCache.

But I'm somewhat confused what this has to do with Andres's report.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates
Следующее
От: Robert Haas
Дата:
Сообщение: Re: use_remote_estimate usage for join pushdown in postgres_fdw