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 по дате отправления:

Предыдущее
От: Shlok Kyal
Дата:
Сообщение: Re: Extend pgbench partitioning to pgbench_history
Следующее
От: Shlok Kyal
Дата:
Сообщение: Re: Extend pgbench partitioning to pgbench_history