On Mon, 13 Jul 2026 at 18:18, vignesh C <[email protected]> wrote: > > On Wed, 8 Jul 2026 at 14:50, Fujii Masao <[email protected]> wrote: > > > > On Thu, Jul 2, 2026 at 6:55 PM Amit Kapila <[email protected]> wrote: > > > > How about something like this instead? > > > > > > > > This function returns a row of NULL values if the specified relation > > > > OID does not exist, if it is not a sequence, if the current user > > > > lacks > > > > <literal>SELECT</literal> privilege on the sequence, if the sequence > > > > is another session's temporary sequence, or if it is an unlogged > > > > sequence on a standby server. > > > > > > > > > > Sounds reasonable. But after this we don't need the next para to say: > > > "It requires <literal>SELECT</literal> privilege on the sequence.". > > > See attached. > > > > Thanks for the patch! I've pushed it. > > > > > > I've updated the patch furthermore. Attached. > > > > > > > > > > LGTM. > > > > Thanks for the review! I've pushed this as well. > > There was an issue reported by Noah at [1], the finding-7 reported > fails with an assert. The assertion can be triggered if a sequence is > dropped concurrently while the sequence synchronization worker is > processing it: > TRAP: failed Assert("!isnull"), File: "sequencesync.c", Line: 298, PID: 25085 > 0 postgres ExceptionalCondition > 1 postgres get_and_validate_seq_info > 2 postgres copy_sequences > 3 postgres LogicalRepSyncSequences > 4 postgres start_sequence_sync > 5 postgres SequenceSyncWorkerMain > > It can be reproduced with the following steps: > Session 1: > BEGIN; > DROP SEQUENCE s1; > > Session 2: > ALTER SUBSCRIPTION ... REFRESH SEQUENCES; > > Session 1: > COMMIT; > > The assertion occurs because the sequence is dropped after the > sequence synchronization worker has collected the sequence metadata > but before it retrieves the sequence data. In this case, > 'has_sequence_privilege_id()' calls 'get_rel_relkind()', which can no > longer find the relation in the syscache and therefore returns 'NULL'. > 'get_and_validate_seq_info()' currently assumes that the privilege > column is never 'NULL' and triggers the assertion. > > I've attached a patch to handle this case by treating a 'NULL' > privilege value as indicating that the sequence no longer exists and > reporting it through the existing "missing sequence on publisher" > path. > Thoughts?
Sorry, I missed sharing the link in the previous mail. The link for the same is: [1] - https://www.postgresql.org/message-id/20260710045217.f0.noahmisch%40microsoft.com Regards, Vignesh
