Re: pg_dump crash on identity sequence with not loaded attributes

Поиск
Список
Период
Сортировка
От Artur Zakirov
Тема Re: pg_dump crash on identity sequence with not loaded attributes
Дата
Msg-id CAKNkYnz-uX2fk_V6bdp+KvFTCU8RtPG-k8MfMkgWRnM7nHoyQg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_dump crash on identity sequence with not loaded attributes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_dump crash on identity sequence with not loaded attributes
Список pgsql-bugs
On Tue, 10 Dec 2024 at 19:08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Artur Zakirov <zaartur@gmail.com> writes:
> > Alternatively, instead of forcing owning_tab->interesting to true, I
> > think we could always initialize owning_tab's attributes (i.e. arrays
> > like owning_tab->attnames, owning_tab->attidenity), which are used by
> > dumpSequence() and which causes the crash. Are there any downsides of
> > it?
>
> Lots.  The entire point of the ->interesting flag is to avoid fetching
> additional details about tables that we don't really care about.
> Unless I misunderstand, you're proposing throwing away that whole
> optimization, which has got to be an overall loss.

Yeah, I rechecked the code and it seems getTableAttrs() is called
later than getOwnedSeqs(). And we can set owning_tab->interesting to
true to load data only of needed tables.

I think it will still be necessary to negate DUMP_COMPONENT_DEFINITION
from seqinfo->dobj.dump because we shouldn't dump statements like ...
ALTER COLUMN ... ADD GENERATED ..., if the table's definition isn't
dumped.

-- 
Kind regards,
Artur



В списке pgsql-bugs по дате отправления: