On Fri, Feb 17, 2023 at 4:48 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Fri, Feb 17, 2023 at 10:58 AM Zheng Li <zhengl...@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