Re: Random pg_upgrade test failure on drongo
| От | Alexander Lakhin |
|---|---|
| Тема | Re: Random pg_upgrade test failure on drongo |
| Дата | |
| Msg-id | 15912ca7-8db5-e720-1860-14eff30170ab@gmail.com обсуждение |
| Ответ на | Re: Random pg_upgrade test failure on drongo (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: Random pg_upgrade test failure on drongo
|
| Список | 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
В списке pgsql-hackers по дате отправления: