On Thu, Feb 8, 2024, at 12:04 AM, Hayato Kuroda (Fujitsu) wrote:
>
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?
If someone modifies data after promotion, fine; she has to deal with conflicts,
if any. IMO it is solved adding one or two sentences in the documentation.
>
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.
Ditto.
>
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 = ''
It can be implemented later if people are excited by it.
are not needed, right? IIUC inconsistency of -P may be still problematic.
I still think we shouldn't have only the transformed primary_conninfo as
option.
>
pglogical_create_subscriber does nothing [2][3].
>
Oh, thanks.
Just to confirm - pglogical set shared_preload_libraries to '', should we follow or not?
The in-core logical replication does not require any library to be loaded.
