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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Cluster "stuck" in "not accepting commands to avoid wraparound data loss"
Дата
Msg-id 20151216175616.GB14238@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Cluster "stuck" in "not accepting commands to avoid wraparound data loss"  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
On 2015-12-11 10:08:32 -0800, Jeff Janes wrote:
> This is still in regular mode, correct?

Yes.

> I don't think this has ever worked.  Vacuum needs to start a
> transaction in order to record its update of datfrozenxid and
> relfrozenxid to the catalogs (or at least, starts one for something).
> Once you are within 1,000,000 of wraparound, you have to do the vacuum
> in single-user mode, you can no longer just wait for autovacuum to do
> its thing.  Otherwise the vacuum will do all the work of the vacuum,
> but then fail to clear the error condition.

But since we don't have, afaik, any code to handle that we should still
be starting workers to do the truncation. Which isn't happening here.

But more importantly, it *should* be impossible to have that combination
of oldestXid values with the datfrozenxid values.

> Could the database have undergone a crash and recovery cycle?

Could, but I don't think it has before the problem occurred. The first
pgbench failure was about not being able to assign xids anymore.

Greetings,

Andres Freund



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: use_remote_estimate usage for join pushdown in postgres_fdw
Следующее
От: Tom Lane
Дата:
Сообщение: Re: fix for readline terminal size problems when window is resized with open pager