On 6/30/25 08:36, Achilleas Mantzios wrote:
Hi,
I gotta provide again a logical repl subscriber for our devs, we are
running PostgreSQL 16.9 .
Instead of going the traditional logical replication way (which
involves long running COPY, catchup, etc), I am thinking of doing
something along the lines :
1) @publisher (master) create repl slot, create publication
2) shutdown postgresql ,
3) clone the VM,
4) boot the clone (subscriber),
5) @subscriber start postgresql , drop publication, drop replication
slot, create the subscription using repl slot of 1)
6) @master start postgresql .
or a version with less downtime for the publisher (aka master ,
primary) :
1) @publisher (master) create repl slot, create publication
2) shutdown postgresql ,
3) clone the VM,
4) start master,
5) boot the clone (subscriber),
6) @subscriber start postgresql , drop the publication, drop the
replication slot, create the subscription using repl slot of 1)
do you find any gotchas in the above ?
It seems I missed the fact that between 1) and 2) there could be INSERTs
that are both logged in the slot and also in the data files. This will
create conflicts upon creating the SUBSCRIPTION on steps 5) or 6)
respectively. Unless I prohibit any connections before step 1)
