Re: pg_dump crash on identity sequence with not loaded attributes - Mailing list pgsql-bugs

From Artur Zakirov
Subject Re: pg_dump crash on identity sequence with not loaded attributes
Date
Msg-id CAKNkYnz-uX2fk_V6bdp+KvFTCU8RtPG-k8MfMkgWRnM7nHoyQg@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump crash on identity sequence with not loaded attributes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump crash on identity sequence with not loaded attributes
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump crash on identity sequence with not loaded attributes
Next
From: Tom Lane
Date:
Subject: Re: pg_dump crash on identity sequence with not loaded attributes