Re: Support logical replication of global object commands

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Zheng Li <zhengli10(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Support logical replication of global object commands
Date: 2023-02-17 09:47:52
Message-ID: CAA4eK1+c8vetrm1-CZ53_KaatpPoQqHVJbOQyoPvcZ-=My7y1w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 17, 2023 at 10:58 AM Zheng Li <zhengli10(at)gmail(dot)com> wrote:
>
> > > > Actually, I intend something for global objects. But the main thing
> > > > that is worrying me about this is that we don't have a clean way to
> > > > untie global object replication from database-specific object
> > > > replication.
> > >
> > > I think ultimately we need a clean and efficient way to publish (and
> > > subscribe to) any changes in all databases, preferably in one logical
> > > replication slot.
> > >
> >
> > Agreed. I was thinking currently for logical replication both
> > walsender and slot are database-specific. So we need a way to
> > distinguish the WAL for global objects and then avoid filtering based
> > on the slot's database during decoding.
>
> But which WALSender should handle the WAL for global objects if we
> don't filter by database? Is there any specific problem you see for
> decoding global objects commands in a database specific WALSender?
>

I haven't verified but I was concerned about the below check:
logicalddl_decode
{
...
+
+ if (message->dbId != ctx->slot->data.database ||

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2023-02-17 10:22:54 The output sql generated by pg_dump for a create function refers to a modified table name
Previous Message Stephen Frost 2023-02-17 09:27:28 Re: Kerberos delegation support in libpq and postgres_fdw