Re: Cluster "stuck" in "not accepting commands to avoid wraparound data loss" - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Cluster "stuck" in "not accepting commands to avoid wraparound data loss"
Date
Msg-id 20151216175616.GB14238@awork2.anarazel.de
Whole thread Raw
In response to Re: Cluster "stuck" in "not accepting commands to avoid wraparound data loss"  (Jeff Janes <jeff.janes@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: use_remote_estimate usage for join pushdown in postgres_fdw
Next
From: Tom Lane
Date:
Subject: Re: fix for readline terminal size problems when window is resized with open pager