Re: prion failed with ERROR: missing chunk number 0 for toast value 14334 in pg_toast_2619

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Justin Pryzby <pryzby(at)telsasoft(dot)com>
Subject: Re: prion failed with ERROR: missing chunk number 0 for toast value 14334 in pg_toast_2619
Date: 2021-05-16 23:28:33
Message-ID: 20210516232833.qfrjcb7jgbzzpo5h@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-05-16 18:42:53 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > Why would it not be safe?
>
> I'm just wondering about the catalog tuples set up by pg_upgrade
> itself. If they're all frozen then they probably don't matter to
> this, but it might take some thought.

There shouldn't be any catalog objects (vs tuples) set up by pg_upgrade
at the time of the resetwal, as far as I can see. copy_xact_xlog_xid(),
which includes the resetwal calls, is done before any new objects are
created/restored.

The only thing that happens before copy_xact_xlog_xid() is
prepare_new_cluster(), which analyzes/freezes the catalog of the new
cluster. Of course that does create new stats tuples for catalog tables,
but if the freezing of those doesn't work, we'd be in deep trouble
regardless of which concrete oldestXid value we choose - that happens
with xids as they are in a freshly initdb' cluster, which might be in
the future in the old cluster, or might have aborted. Their pg_xact will
be overwritten in copy_xact_xlog_xid().

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2021-05-17 00:19:41 Re: Typo in README.barrier
Previous Message Tom Lane 2021-05-16 22:42:53 Re: prion failed with ERROR: missing chunk number 0 for toast value 14334 in pg_toast_2619