Re: Random pg_upgrade test failure on drongo - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Random pg_upgrade test failure on drongo
Date
Msg-id CAA4eK1+tx7YiZHjOGkpd5jHudWaHdX0z_1Rd_B6o4RXGxUYYAA@mail.gmail.com
Whole thread Raw
In response to Re: Random pg_upgrade test failure on drongo  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: Random pg_upgrade test failure on drongo
List pgsql-hackers
On Wed, Jan 10, 2024 at 3:30 PM Alexander Lakhin <exclusion@gmail.com> wrote:
>
> 10.01.2024 12:31, Amit Kapila wrote:
> > I am slightly hesitant to add any particular system table name in the
> > comments as this can happen for any other system table as well, so
> > slightly adjusted the comments in the attached. However, I think it is
> > okay to mention the particular system table name in the commit
> > message. Let me know what do you think.
>
> Thank you, Amit!
>
> I'd like to note that the culprit is exactly pg_largeobject as coded in
> dumpDatabase():
>      /*
>       * pg_largeobject comes from the old system intact, so set its
>       * relfrozenxids, relminmxids and relfilenode.
>       */
>      if (dopt->binary_upgrade)
> ...
>          appendPQExpBufferStr(loOutQry,
>                               "TRUNCATE pg_catalog.pg_largeobject;\n");
>
> I see no other TRUNCATEs (or similar logic) around, so I would specify the
> table name in the comments. Though maybe I'm missing something...
>

But tomorrow it could be for other tables and if we change this
TRUNCATE logic for pg_largeobject (of which chances are less) then
there is always a chance that one misses changing this comment. I feel
keeping it generic in this case would be better as the problem is
generic but it is currently shown for pg_largeobject.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Documentation to upgrade logical replication cluster
Next
From: Andrew Dunstan
Date:
Subject: Re: WIP Incremental JSON Parser