Re: found xmin x from before relfrozenxid y

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Johannes Graën <johannes(at)selfnet(dot)de>, pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: found xmin x from before relfrozenxid y
Date: 2018-10-22 01:01:05
Message-ID: 20181022010105.v4wzvjhpqhmlz2zu@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Hi,

On 2018-10-21 10:24:16 -0400, Tom Lane wrote:
> =?UTF-8?Q?Johannes_Gra=c3=abn?= <johannes(at)selfnet(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David Rowley 2018-10-22 01:50:47 Re: Help with list partitioning on expression
Previous Message legrand legrand 2018-10-21 22:18:33 Re: no queryId in post_parse_analyze hook when row is locked

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-10-22 02:09:09 Re: relhassubclass and partitioned indexes
Previous Message Stephen Frost 2018-10-22 00:56:32 Re: More issues with pg_verify_checksums and checksum verification in base backups