Feedback-ID: i0c21471d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61
MIME-Version: 1.0
Message-Id: <2edde173-5ff9-45fd-b881-cd04eb13049f@app.fastmail.com>
In-Reply-To: 
 <TYCPR01MB12077835F614EF829BB035120F5442@TYCPR01MB12077.jpnprd01.prod.outlook.com>
References: <9a9c7e65-c47b-4400-a63e-ac6169c0860e@app.fastmail.com>
 <CAFcNs+qAMdzd_73gwo3UE_25h+E-sHiV2paxfDgz=xw2y7hogw@mail.gmail.com>
 <TY3PR01MB9889D0FF89D502539340EA03F5432@TY3PR01MB9889.jpnprd01.prod.outlook.com>
 <TY3PR01MB9889F3C46DC76CE77B91FB58F5432@TY3PR01MB9889.jpnprd01.prod.outlook.com>
 <TY3PR01MB98894646568B37FE11E9CC0DF5432@TY3PR01MB9889.jpnprd01.prod.outlook.com>
 <8d8d9960-8130-4216-b0e4-adf36b8b1c43@app.fastmail.com>
 <TY3PR01MB98896B904BB259B559622773F5422@TY3PR01MB9889.jpnprd01.prod.outlook.com>
 <370673e8-e2da-4249-8f07-cb67e9d9c20e@app.fastmail.com>
 <TYCPR01MB120779A0CC2083C1DA8534BA7F5452@TYCPR01MB12077.jpnprd01.prod.outlook.com>
 <34075bd4-c85d-4654-a782-0cd6713b2c89@app.fastmail.com>
 <TYCPR01MB12077835F614EF829BB035120F5442@TYCPR01MB12077.jpnprd01.prod.outlook.com>
Date: Tue, 13 Feb 2024 23:56:43 -0300
From: "Euler Taveira" <euler@eulerto.com>
To: "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>
Cc: 
 "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
 "vignesh C" <vignesh21@gmail.com>, "Michael Paquier" <michael@paquier.xyz>,
 "Peter Eisentraut" <peter@eisentraut.org>,
 "Andres Freund" <andres@anarazel.de>,
 "Ashutosh Bapat" <ashutosh.bapat.oss@gmail.com>,
 "Amit Kapila" <amit.kapila16@gmail.com>,
 "Shlok Kyal" <shlok.kyal.oss@gmail.com>,
 =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabriziomello@gmail.com>
Subject: Re: speed up a logical replica setup
Content-Type: multipart/alternative;
 boundary=71a48a97ccbc461fae7590d458dbc01c
Archived-At: <https://www.postgresql.org/message-id/2edde173-5ff9-45fd-b881-cd04eb13049f%40app.fastmail.com>
Precedence: bulk

--71a48a97ccbc461fae7590d458dbc01c
Content-Type: text/plain

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.


--
Euler Taveira
EDB   https://www.enterprisedb.com/

--71a48a97ccbc461fae7590d458dbc01c
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Thu, Fe=
b 8, 2024, at 12:04 AM, Hayato Kuroda (Fujitsu) wrote:<br></div><blockqu=
ote type=3D"cite" id=3D"qt" style=3D""><div>&gt;<br></div><div>Remember =
the target server was a standby (read only access). I don't expect an<br=
></div><div>application trying to modify it; unless it is a buggy applic=
ation.<br></div><div>&gt;<br></div><div><br></div><div>What if the clien=
t modifies the data just after the promotion?<br></div><div>Naively cons=
idered, all the changes can be accepted, but are there any issues?<br></=
div></blockquote><div><br></div><div>If someone modifies data after prom=
otion, fine; she has to deal with conflicts,<br></div><div>if any. IMO i=
t is solved adding one or two sentences in the documentation.<br></div><=
div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt;<b=
r></div><div>Regarding<br></div><div>GUCs, almost all of them is PGC_POS=
TMASTER (so it cannot be modified unless the<br></div><div>server is res=
tarted). The ones that are not PGC_POSTMASTER, does not affect the<br></=
div><div>pg_createsubscriber execution [1].<br></div><div>&gt;<br></div>=
<div><br></div><div>IIUC,&nbsp; primary_conninfo and primary_slot_name i=
s PGC_SIGHUP.<br></div></blockquote><div><br></div><div>Ditto.<br></div>=
<div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt;<=
br></div><div>I'm just pointing out that this case is a different from p=
g_upgrade (from which<br></div><div>this idea was taken). I'm not saying=
 that's a bad idea. I'm just arguing that<br></div><div>you might be pre=
venting some access read only access (monitoring) when it is<br></div><d=
iv>perfectly fine to connect to the database and execute queries. As I s=
aid<br></div><div>before, the current UI allows anyone to setup the stan=
dby to accept only local<br></div><div>connections. Of course, it is an =
extra step but it is possible. However, once<br></div><div>you apply v16=
-0007, there is no option but use only local connection during the<br></=
div><div>transformation. Is it an acceptable limitation?<br></div><div>&=
gt;<br></div><div><br></div><div>My remained concern is written above. I=
f they do not problematic we may not have<br></div><div>to restrict them=
 for now. At that time, changes&nbsp;<br></div><div><br></div><div>1) ov=
erwriting a port number,<br></div><div>2) setting listen_addresses =3D '=
'<br></div></blockquote><div><br></div><div>It can be implemented later =
if people are excited by it.<br></div><div><br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div>are not needed, right? IIUC inconsisten=
cy of -P may be still problematic.<br></div></blockquote><div><br></div>=
<div>I still think we shouldn't have only the transformed primary_connin=
fo as<br></div><div>option.<br></div><div><br></div><blockquote type=3D"=
cite" id=3D"qt" style=3D""><div>&gt;<br></div><div>pglogical_create_subs=
criber does nothing [2][3].<br></div><div>&gt;<br></div><div><br></div><=
div>Oh, thanks.<br></div><div>Just to confirm - pglogical set shared_pre=
load_libraries to '', should we follow or not?<br></div></blockquote><di=
v><br></div><div>The in-core logical replication does not require any li=
brary to be loaded.<br></div><div><br></div><div><br></div><div id=3D"si=
g112409080"><div class=3D"signature">--<br></div><div class=3D"signature=
">Euler Taveira<br></div><div class=3D"signature">EDB&nbsp;&nbsp; <a hre=
f=3D"https://www.enterprisedb.com/">https://www.enterprisedb.com/</a><br=
></div></div><div><br></div></body></html>
--71a48a97ccbc461fae7590d458dbc01c--