Re: speed up a logical replica setup

Did you consider adding options for publication/subscription/slot

names as mentioned in my previous email? As discussed in a few emails

above, it would be quite confusing for users to identify the logical

replication objects once the standby is converted to subscriber.

It seems we care only for publications created on the primary. Isn't

it possible that some of the publications have been replicated to

standby by that time, for example, in case failure happens after

creating a few publications? IIUC, we don't care for standby cleanup

after failure because it can't be used for streaming replication

anymore. So, the only choice the user has is to recreate the standby

and start the pg_createsubscriber again. This sounds questionable to

me as to whether users would like this behavior. Does anyone else have

an opinion on this point?

I see the below note in the patch:

+    If <application>pg_createsubscriber</application> fails while processing,

+    then the data directory is likely not in a state that can be recovered. It

+    is true if the target server was promoted. In such a case, creating a new

+    standby server is recommended.

By reading this it is not completely clear whether the standby is not

recoverable in case of any error or only an error after the target

server is promoted. If others agree with this behavior then we should

write the detailed reason for this somewhere in the comments as well

unless it is already explained.