Re: pg_dump crash on identity sequence with not loaded attributes

On Tue, 10 Dec 2024 at 16:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I think it is necessary to use negation in this condition.
>
> D'oh, of course.  But what's your thoughts on the other points?
> Is this what we want to do at all?

Alternatively I was thinking about this change:

                        continue;
                }

+               if (!(owning_tab->dobj.dump & DUMP_COMPONENT_DEFINITION) &&
+                       seqinfo->is_identity_sequence)
+                       seqinfo->dobj.dump &= ~DUMP_COMPONENT_DEFINITION;
+
                /*
                 * Otherwise we need to dump the components that are
being dumped for
                 * the table and any components which the sequence is explicitly

This way we wouldn't ignore ACLs for example. Currently a user might
not have permissions to a sequence but still be able to read/write to
its table if they have permissions. Although the user cannot execute
nextval/setval explicitly.
If an admin grants permissions to the sequence explicitly (for some
reason) the user will be able to execute nextval/setval. And that will
be lost during dump/restore. Currently this doesn't work at all and
ignoring sequences won't break anything.

Ideally I would like to have the ability to dump ACL of those
sequences too, even though this looks like a quite narrow use case.

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?

-- 
Kind regards,
Artur