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
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 |
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 |