On Monday, August 21, 2023 11:21 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Sun, Aug 20, 2023 at 6:49 PM Masahiko Sawada > <sawada.m...@gmail.com> wrote: > > > > On Thu, Aug 17, 2023 at 10:31 PM Amit Kapila <amit.kapil...@gmail.com> > wrote: > > > > > > > > > > > Sorry I was not clear. I meant the logical replication slots that > > > > are > > > > *not* used by logical replication, i.e., are created manually and > > > > used by third party tools that periodically consume decoded > > > > changes. As we discussed before, these slots will never be able to > > > > pass that confirmed_flush_lsn check. > > > > > > > > > > I think normally one would have a background process to periodically > > > consume changes. Won't one can use the walsender infrastructure for > > > their plugins to consume changes probably by using replication > > > protocol? > > > > Not sure. > > > > I think one can use Streaming Replication Protocol to achieve it [1]. > > > > Also, I feel it is the plugin author's responsibility to consume > > > changes or advance slot to the required position before shutdown. > > > > How does the plugin author ensure that the slot consumes all WAL > > records including shutdown_checkpoint before shutdown? > > > > By using "Streaming Replication Protocol" so that walsender can take care of > it. > If not, I think users should drop such slots before the upgrade because > anyway, > they won't be usable after the upgrade.
Yes, I think pglogical is one example which start a bgworker(apply worker) on client to consume changes which also uses Streaming Replication Protocol IIRC. And pg_recvlogical is another example which connects to walsender and consume changes. Best Regards, Hou zj
