Re: Add a hook for handling logical decoding messages on subscribers.

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add a hook for handling logical decoding messages on subscribers.
Date: 2026-10-16 22:16:18
Message-ID: CALj2ACVuHCZJ2vdrbB22LG77gCjwsw2DYcqNEy8GuHuKe_1Agg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Fri, Oct 16, 2026 at 2:45 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> > > 4. Based on above two points, I think we can fill the hole with something like:
>
> > > CREATE SUBSCRIPTION ... WITH (messages = true, message_handler_role =
> > > 'msg_handler')
>
> > > and then run the hook under SwitchToUntrustedUser(that_role). That
>
> > I like this idea more than all the other approaches.
>
> My concern is that since the handler is a C function, this doesn't
> help much as a security boundary. The handler can get back to the
> subscription owner by calling SetUserIdAndSecContext() with
> MySubscription->owner or even switch to the superuser. That function
> does no permission check, and since the security context is its second
> argument, the same call clears SECURITY_RESTRICTED_OPERATION as well.
> As I mentioned in the reply to Amit, the option would help in cases
> where the handler doesn't switch to the target role, or forgets to,
> and keeps working as the subscription owner unexpectedly. But I'm not
> sure we need this option just for that case.

Agreed. In a way, we already trust every hook as far as switching to
whatever role with SetUserIdAndSecContext() is concerned. So
documenting the risk clearly here works for me.

> > > I think we should have a similar ERROR for parallel apply worker.
>
> > Also, error out for the sequence sync worker?
>
> I agree to add a check for parallel apply workers, but I don't think
> we need it for the sequence sync workers as they neither enter the
> apply loop nor receive logical replication changes in the first place.

Right, we don't need to error out for seq sync workers. However, do we
need to error out for the table sync worker, since we don't expect a
logical message there?

+ /*
+ * Logical messages are relation-agnostic, so they don't map cleanly onto
+ * the tablesync worker of a particular relation, and there would be no
+ * well-defined ordering between a message and the initial copy. Leave
+ * them to the (parallel) apply workers.
+ */

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2026-10-16 22:25:00 Re: Use WALReadFromBuffers in more places
Previous Message Zsolt Parragi 2026-10-16 22:14:28 Re: Prevent foreign key references to unlogged partitions