On Fri, Feb 17, 2023 at 4:48 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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 ||
OK, let's suppose we don't filter by database for global commands when
decoding ddl records, roughly what the following code does:
logicalddl_decode
{
...
if (message->dbId != ctx->slot->data.database ||
+ message->cmdtype != DCT_GlobalObjectCmd
But this is not enough, we also need the subsequent commit record of
the txn to be decoded in order to replicate the global command. So I
think we also need to make DecodeCommit bypass the filter by database
if global object replication is turned on and we have decoded a global
command in the txn.
Regards,
Zane
