Re: found xmin x from before relfrozenxid y

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Johannes Graën <johannes(at)selfnet(dot)de>
Cc: 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-21 14:24:16
Message-ID: 3266.1540131856@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

=?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.

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

In the meantime, the only answer I can think of offhand is to manually
do VACUUM FREEZE on each of your MVs, and then refresh anything that
shows up with an error.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Johannes Graën 2018-10-21 14:57:15 Re: found xmin x from before relfrozenxid y
Previous Message Andy Colson 2018-10-21 13:52:50 Re: Postgres 10, slave not catching up with master

Browse pgsql-hackers by date

  From Date Subject
Next Message Johannes Graën 2018-10-21 14:57:15 Re: found xmin x from before relfrozenxid y
Previous Message Michael Paquier 2018-10-21 13:42:06 More issues with pg_verify_checksums and checksum verification in base backups