| From: | Zhijie Hou <houzhijie22(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, vignesh C <vignesh21(at)gmail(dot)com> |
| Subject: | Re: [PG19] Sequence sync stops when the subscription owner can't SET ROLE to a sequence owner |
| Date: | 2026-10-20 05:05:32 |
| Message-ID: | CAFvd2n8Tk=onwnGu9FW1i6o60_Y181OjBPygv085SuiQf3aFQA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Tue, Oct 20, 2026 at 12:33 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Oct 16, 2026 at 10:48 PM Zsolt Parragi
> <zsolt(dot)parragi(at)percona(dot)com> 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.
I agree that we cannot catch all possible errors. After thinking about this
more, there are other errors—such as deadlock timeout or lock timeout—that
cannot easily be pre-checked, so adding an error context looks like a good
approach to me. Attached is a patch that adds the error context as
suggested.
Best Regards,
Zhijie Hou
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Add-error-context-for-sequence-synchronization.patch | application/octet-stream | 6.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Manu | 2026-10-20 05:09:19 | Re: doc: Document Linux cgroup memory limits |
| Previous Message | Tom Lane | 2026-10-20 04:46:43 | Re: [PATCH] initdb: map Windows' new Canadian time zone names |