Re: Support logical replication of DDLs

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: "Jonathan S. Katz" <jkatz@postgresql.org>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, Ajin Cherian <itsajin@gmail.com>, Peter Smith <smithpb2250@gmail.com>, vignesh C <vignesh21@gmail.com>, Zheng Li <zhengli10@gmail.com>, li jie <ggysxcq@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Japin Li <japinli@hotmail.com>, rajesh singarapu <rajesh.rs0541@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-02-20T04:14:48Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add a run_as_owner option to subscriptions.

  2. Refactor pgoutput_change().

  3. Print the correct aliases for DML target tables in ruleutils.

  4. Fix object identity string for transforms

  5. Add grantable MAINTAIN privilege and pg_maintain role.

  6. Get rid of recursion-marker values in enum AlterTableType

  7. Release cache tuple when no longer needed

  8. Empty search_path in logical replication apply worker and walsender.

  9. Refactor format_type APIs to be more modular

  10. Use wrappers of PG_DETOAST_DATUM_PACKED() more.

On Sun, Feb 19, 2023 at 7:50 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> On 2/17/23 4:15 AM, Amit Kapila wrote:
>
> > This happens because of the function used in the index expression.
> > Now, this is not the only thing, the replication can even fail during
> > DDL replication when the function like above is IMMUTABLE and used as
> > follows: ALTER TABLE tbl ADD COLUMN d int DEFAULT t(1);
> >
> > Normally, it is recommended that users can fix such errors by
> > schema-qualifying affected names. See commits 11da97024a and
> > 582edc369c.
>
> I'm very familiar with those CVEs, but even though these are our
> recommended best practices, there is still a lot of code that does not
> schema-qualify the names of functions (including many of our own examples ;)
>
> If we're going to say "You can use logical replication to replicate
> functions, but you have to ensure you've schema-qualified any function
> calls within them," I think that will prevent people from being able to
> use this feature, particularly on existing applications.
>

I agree with this statement.

> I guess there's a connection I'm missing here. For the failing examples
> above, I look at the pg_proc entries on both the publisher and the
> subscriber and they're identical. I'm not understanding why creating and
> executing the functions works on the publisher, but it does not on the
> subscriber.
>

It is because on the subscriber, in apply worker, we override the
search path to "". See

InitializeApplyWorker()
{
...
/*
* Set always-secure search path, so malicious users can't redirect user
* code (e.g. pg_index.indexprs).
*/
SetConfigOption("search_path", "", PGC_SUSET, PGC_S_OVERRIDE);
...

This has been done to ensure that apply worker doesn't execute
arbitrary expressions as currently, it works with the privileges of
the subscription owner which would be a superuser.

> What additional info would the subscriber need to be able to
> successfully run these functions? Would we need to pass in some
> additional context, e.g. what the search_path was at the time the
> publisher created the function?
>

Yeah, I think search_path is required. I think we need some way to
avoid breaking what we have done in commit 11da97024a and that also
allows us to refer to objects without schema qualification in
functions. Will it be sane to allow specifying search_path for a
subscription via Alter Subscription? Can we think of any other way
here?

-- 
With Regards,
Amit Kapila.