Re: pg_dump crash on identity sequence with not loaded attributes

On Tue, 10 Dec 2024 at 16:29, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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