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

Hi,

On 5/17/21 1:28 AM, Andres Freund wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> 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().

FWIW a patch proposal to copy the oldest unfrozen XID during pg_upgrade
(it adds a new (- u) parameter to pg_resetwal) has been submitted a
couple of weeks ago, see: https://commitfest.postgresql.org/33/3105/

I was also wondering if:

* We should keep the old behavior in case pg_resetwal -x is being used
without -u?
 (The proposed patch does not set an arbitrary oldestXID
anymore in 
case -x is used)
* We should ensure that the xid provided with -x or -u is
>=
FirstNormalTransactionId (Currently the only check is that it is
# 0)?

Thanks

Bertrand