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