Re: found xmin x from before relfrozenxid y - Mailing list pgsql-general

From Andres Freund
Subject Re: found xmin x from before relfrozenxid y
Date
Msg-id 20181022010105.v4wzvjhpqhmlz2zu@alap3.anarazel.de
Whole thread Raw
In response to Re: found xmin x from before relfrozenxid y  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Hi,

On 2018-10-21 10:24:16 -0400, Tom Lane wrote:
> =?UTF-8?Q?Johannes_Gra=c3=abn?= <johannes@selfnet.de> writes:
> > after upgrading to version 11, I see the error pattern "found xmin x
> > from before relfrozenxid y" in different databases on different hosts.
> > From https://www.postgresql.org/docs/10/static/release-10-3.html, I
> > learned that this was an error caused by pg_upgrade, which apparently
> > had been fixed in 10.3. This page also states that refreshing the
> > affected materialized view non-concurrently would fix the problem.
> > My question is now how to infer the affected materialized view from the
> > error message. Is there a way to tell which one to refresh from the xmin
> > or relfrozenxid value?
> 
> No :-(.  I wonder why in the world we didn't make that error message
> include the relation and block number the tuple was found in.

Because it was a really complicated bugfix already, I don't think the
answer is more complicated than that.


> (Well, I see the short answer: the code layer throwing the error
> doesn't know.  But that could be fixed easily enough.)

I wonder if the better approach wouldn't be to add an errcontext for
vaccuum, where continually update the block number etc. Theres plenty of
different sources of corruption that'd potentially cause debug messages
or errors, and that should get most of them.

Greetings,

Andres Freund


pgsql-general by date:

Previous
From: legrand legrand
Date:
Subject: Re: no queryId in post_parse_analyze hook when row is locked
Next
From: David Rowley
Date:
Subject: Re: Help with list partitioning on expression