From: | Hannes Erven <hannes(at)erven(dot)at> |
---|---|
To: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | "Cascading Logical Replication" from a physical replica |
Date: | 2017-11-13 22:08:16 |
Message-ID: | 67a6df16-278e-bfde-cd70-11f8a8beabef@erven.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
as of PG10, it is not possible to create logical replication slots on
standby servers.
Should that fact probably be mentioned more explicitly in
https://www.postgresql.org/docs/10/static/logical-replication.html ?
There seems to be work by Craig Ringer going on, but that doesn't seem
to be arriving soon...
https://commitfest.postgresql.org/12/788/
My requirement is to be notified of any row changes
(insert/update/delete) that become visible on a standby server through
streaming physical replication.
Table name and primary key would be sufficient, I don't need the actual
row data. And there's no "replication" at all ;-)
Is this something that pglogical
(https://www.2ndquadrant.com/en/resources/pglogical/ ) or pgxlogdump
could provide?
The workaround I've come up so far would be: connect logical replication
to the master and extract the events I'm interested together with the
WAL position of the corresponding TX's commit.
Then, send that information to each replica; connect locally and poll
the replayed WAL position every second or so. Work on the events that
became visible and queue the rest.
But this seems to be quite complex compared to just reading the WAL off
the standby where it already is, ideally using the logical output plugin
interface to format the data.
Thanks for any insights!
Best regards,
-hannes erven
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-11-13 23:44:11 | Re: PG-10 + ICU and abbreviated keys |
Previous Message | Andreas Joseph Krogh | 2017-11-13 22:05:46 | Re: PG-10 + ICU and abbreviated keys |