Re: Support logical replication of global object commands - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Support logical replication of global object commands
Date
Msg-id CAA4eK1+c8vetrm1-CZ53_KaatpPoQqHVJbOQyoPvcZ-=My7y1w@mail.gmail.com
Whole thread Raw
In response to Re: Support logical replication of global object commands  (Zheng Li <zhengli10@gmail.com>)
Responses Re: Support logical replication of global object commands
List pgsql-hackers
On Fri, Feb 17, 2023 at 10:58 AM Zheng Li <zhengli10@gmail.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.



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Kerberos delegation support in libpq and postgres_fdw
Next
From: vignesh C
Date:
Subject: The output sql generated by pg_dump for a create function refers to a modified table name