| From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "andrew(at)dunslane(dot)net" <andrew(at)dunslane(dot)net> |
| Subject: | Re: Random pg_upgrade test failure on drongo |
| Date: | 2024-01-10 10:00:01 |
| Message-ID: | 15912ca7-8db5-e720-1860-14eff30170ab@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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...
Best regards,
Alexander
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shlok Kyal | 2024-01-10 10:02:04 | Re: Extend pgbench partitioning to pgbench_history |
| Previous Message | Shlok Kyal | 2024-01-10 09:57:15 | Re: Extend pgbench partitioning to pgbench_history |