On Tue, Jan 20, 2026 at 8:38 AM Hayato Kuroda (Fujitsu)
<[email protected]> wrote:
>
> Dear Alexander,
>
> > FWIW, this issue is not reproduced at 7a485bd64~1, maybe this should be
> > taken into account.
>
> To confirm, are you saying that the issue cannot be reproduced before
> 7a485bd64
> right? I think it's because try_relation_open() is used in
> pg_get_sequence_data().
> Before the commit we forcibly open the relation and raise an ERROR if it
> fails.
> The sequencesync worker exits and tries again - everything is OK.
>
> After the commit, however, we allow to fail opening and the SQL function
> returns
> NULL - this can cause the assertion failure.
>
Right, this is the reason. Similar to the below check [1], introduced
in commit 7a485bd64, we need to check for null values in the
client-side and ERROR out accordingly.
[1]
+ if (entry->null_seqtuple)
+ pg_fatal("failed to get data for sequence
\"%s\"; user may lack "
+ "SELECT privilege on the
sequence or the sequence may "
+ "have been concurrently dropped",
+ tbinfo->dobj.name);
--
With Regards,
Amit Kapila.
