Re: speed up a logical replica setup

>

Remember the target server was a standby (read only access). I don't expect an

application trying to modify it; unless it is a buggy application.

>

What if the client modifies the data just after the promotion?

Naively considered, all the changes can be accepted, but are there any issues?

>

Regarding

GUCs, almost all of them is PGC_POSTMASTER (so it cannot be modified unless the

server is restarted). The ones that are not PGC_POSTMASTER, does not affect the

pg_createsubscriber execution [1].

>

IIUC,  primary_conninfo and primary_slot_name is PGC_SIGHUP.

>

I'm just pointing out that this case is a different from pg_upgrade (from which

this idea was taken). I'm not saying that's a bad idea. I'm just arguing that

you might be preventing some access read only access (monitoring) when it is

perfectly fine to connect to the database and execute queries. As I said

before, the current UI allows anyone to setup the standby to accept only local

connections. Of course, it is an extra step but it is possible. However, once

you apply v16-0007, there is no option but use only local connection during the

transformation. Is it an acceptable limitation?

>

My remained concern is written above. If they do not problematic we may not have

to restrict them for now. At that time, changes 

1) overwriting a port number,

2) setting listen_addresses = ''

are not needed, right? IIUC inconsistency of -P may be still problematic.

>

pglogical_create_subscriber does nothing [2][3].

>

Oh, thanks.

Just to confirm - pglogical set shared_preload_libraries to '', should we follow or not?