From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Cluster "stuck" in "not accepting commands to avoid wraparound data loss" |
Date: | 2015-12-16 17:56:16 |
Message-ID: | 20151216175616.GB14238@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-12-16 18:02:25 | Re: fix for readline terminal size problems when window is resized with open pager |
Previous Message | Robert Haas | 2015-12-16 17:54:42 | Re: use_remote_estimate usage for join pushdown in postgres_fdw |