Re: Resetting recovery target parameters in pg_createsubscriber

On Thu, Oct 30, 2025 at 7:08 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> Can we see this from the different prospective?  pg_createsubscriber
> is intended to turn physical replica into a logical replica. And it
> leaves subscriber database cluster with rudimentary configuration
> options needed purely for its intermediate step.  Whatever usage
> scenario is, user might deleted these extra options if needed.  This
> is not a big deal.  However, it's certainly cleaner for
> pg_createsubscriber to avoid leaving this options (especially if their
> appearance is not documented).

I think that's a fair point. Michael's proposal doesn't sound too bad
to me from that point of view, as it seems to reduce the amount of
machinery that we need to introduce in order to accomplish the goal of
not leaving configuration behind. It's a little unfortunate that
pg_createsubscriber needs to modify the configuration file at all,
rather than say passing flags through on the PostgreSQL command line.
However, doing it that way might make the code a lot more complicated,
and it's not worth a lot of code complexity to avoid leaving recovery
parameters behind given that, as you can say, the user can always just
delete them. Also, to your point, the fact that they will be added
really ought to be documented.

But what I don't want to us to do is write a commit message, or add
tests, that imply that the scenario so far proposed is a reasonable
one. What we were told is that the server is put back into recovery
just after being made into a primary, which seems clearly nonsensical.
You might think of using pg_rewind to put a server back into recovery
after a failover, but in that situation, there is at least 1 standby
following the primary, and you're trying to get them to switch roles.
But here, just after running pg_subscriber, there's no standby yet. If
you put the one and only server with that system ID back into
recovery, there's no other server it can possibly follow, so what's
the point?

Maybe what we could use a scenario is one where the node created by
pg_createsubscriber continues to run as a primary, and eventually
someone creates a standby from it which also inherits its physical
replication configuration and then that cause some kind of problem.
Now, to be fair, that scenario could also happen without using
pg_createsubscriber at all: you could spin up a new primary via PITR,
for example, and that configuration could propagate to standbys
created from the primary and then cause problems, and as far as I know
we do nothing to protect against that. That doesn't mean that we can't
try to protect against this, but I do think it needs to be justified
by reference to a sequence of actions that would be reasonable to
perform on unpatched PostgreSQL. Otherwise, I think we'll be adding to
future confusion in an area that can already be extremely confusing.

--
Robert Haas
EDB: http://www.enterprisedb.com