Re: pg_dump crash on identity sequence with not loaded attributes
Artur Zakirov <zaartur@gmail.com>
From: Artur Zakirov <zaartur@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2024-12-10T18:40:41Z
Lists: 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
Commits
-
Fix possible crash in pg_dump with identity sequences.
- c7f3c414fded 14.16 landed
- b6df2d6e5d83 13.19 landed
- ad950ea98e54 17.3 landed
- 7b8cb9cd6a76 18.0 landed
- 782cc1aa3d15 16.7 landed
- 6978129b4e95 15.11 landed
-
Do not dump identity sequences with excluded parent table
- b965f2617184 12.0 cited