From: | Artur Zakirov <zaartur(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_dump crash on identity sequence with not loaded attributes |
Date: | 2024-12-10 18:40:41 |
Message-ID: | CAKNkYnz-uX2fk_V6bdp+KvFTCU8RtPG-k8MfMkgWRnM7nHoyQg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, 10 Dec 2024 at 19:08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Artur Zakirov <zaartur(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-12-10 21:15:16 | Re: pg_dump crash on identity sequence with not loaded attributes |
Previous Message | Tom Lane | 2024-12-10 18:08:09 | Re: pg_dump crash on identity sequence with not loaded attributes |