On Fri, Oct 16, 2026 at 10:48 PM Zsolt Parragi <[email protected]> wrote: > > With run_as_owner = false, copy_sequence switches to the sequence > owner with SwitchToUntrustedUser before the UPDATE privilege check. If > the subscription owner can't SET ROLE to that owner, it raises an > ERROR and the whole batch is aborted. > > Setup on the subscriber, with 4 sequences in a FOR ALL SEQUENCES publication: > > CREATE ROLE subown LOGIN; CREATE ROLE other; > GRANT pg_create_subscription TO subown; > GRANT CREATE ON DATABASE postgres TO subown; > -- a1, a3, a4 owned by subown, a2 owned by other > CREATE SUBSCRIPTION ss ... WITH (password_required = false, > enabled = false); > ALTER SUBSCRIPTION ss OWNER TO subown; > ALTER SUBSCRIPTION ss ENABLE; > > All 4 sequences stay in INIT, and the log only says: > > ERROR: role "subown" cannot SET ROLE to "other" > > which doesn't say which sequence is the problem. >
I think we can improve this one by using error context, if we want. We have discussed this exact case while fixing other AI reported cases, see [1] (description of finding-3). I think there could be other ERRORs as well and we may not be able to add a check for everything upfront, so, I suggest a general fix for this and other errors where sequence name is displayed with ERROR for now. I am not sure adding more and more defensive checks are really worth it because such cases could be rare in practice and we are giving required information to users so that it can fix the configuration and let sequencesync proceed. [1] - https://www.postgresql.org/message-id/CALDaNm30Cr9n9YLHLnVDMbmUT%3DsegVQF2p0J3NMhUjrE1Mm9cw%40mail.gmail.com -- With Regards, Amit Kapila.
