public inbox for [email protected]
help / color / mirror / Atom feedFrom: Hayato Kuroda (Fujitsu) <[email protected]>
To: 'shveta malik' <[email protected]>
To: Zhijie Hou (Fujitsu) <[email protected]>
To: Amit Kapila <[email protected]>
Cc: Peter Smith <[email protected]>
Cc: Drouvot, Bertrand <[email protected]>
Cc: Nisha Moond <[email protected]>
Cc: Bharath Rupireddy <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Ashutosh Sharma <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Ajin Cherian <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Subject: RE: Synchronizing slots from primary to standby
Date: Thu, 21 Dec 2023 13:07:46 +0000
Message-ID: <TY3PR01MB98893274D5A4FD4F86CC04A0F595A@TY3PR01MB9889.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <CAJpy0uARAi5OFJZ3GqRmx+6_c3tEVfKaswj0_dvmo-2mvjy42w@mail.gmail.com>
References: <OS0PR01MB57166472DB3D01F7407259179496A@OS0PR01MB5716.jpnprd01.prod.outlook.com>
<CAHut+Pv+TW4g2hPrXgu0MbyX6bQ0=0T+JLd2C3b2pEjgakK7CQ@mail.gmail.com>
<OS0PR01MB5716212E157B1453372E893F9495A@OS0PR01MB5716.jpnprd01.prod.outlook.com>
<CAJpy0uARAi5OFJZ3GqRmx+6_c3tEVfKaswj0_dvmo-2mvjy42w@mail.gmail.com>
Dear Shveta,
Thanks for updating the patch! Here is my comments for v52-0002.
~~~~~
system-views.sgml
01.
```
+
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>sync_state</structfield> <type>char</type>
+ </para>
+ <para>
+ Defines slot synchronization state. This is meaningful on the physical
+ standby which has configured <xref linkend="guc-enable-syncslot"/> = true.
+ Possible values are:
+ <itemizedlist>
+ <listitem>
+ <para><literal>n</literal> = none for user created slots,
...
```
Hmm. I'm not sure why we must show a single character to a user. I'm OK for
pg_subscription.srsubstate because it is a "catalog" - the actual value would be
recorded in the heap. But pg_replication_slot is just a view so that we can replace
internal representations to other strings. E.g., pg_replication_slots.wal_status.
How about using {none, initialized, ready} or something?
~~~~~
postmaster.c
02. bgworker_should_start_now
```
+ if (start_time == BgWorkerStart_ConsistentState_HotStandby &&
+ pmState != PM_RUN)
+ return true;
```
I'm not sure the second condition is really needed. The line will be executed when
pmState is PM_HOT_STANDBY. Is there a possibility that pmState is changed around here?
~~~~~
libpqwalreceiver.c
03. PQWalReceiverFunctions
```
+ .walrcv_get_dbname_from_conninfo = libpqrcv_get_dbname_from_conninfo,
```
Just to confirm - is there a rule for ordering?
~~~~~
slotsync.c
04. SlotSyncWorkerCtx
```
typedef struct SlotSyncWorkerCtx
{
pid_t pid;
slock_t mutex;
} SlotSyncWorkerCtx;
SlotSyncWorkerCtx *SlotSyncWorker = NULL;
```
Per other files like launcher.c, should we use a name like "SlotSyncWorkerCtxStruct"?
05. SlotSyncWorkerRegister()
Your coding will work well, but there is another approach which validates
slotsync parameters here. In this case, the postmaster should exit ASAP. This can
notify that there are some wrong settings to users earlier. Thought?
06. wait_for_primary_slot_catchup
```
+ CHECK_FOR_INTERRUPTS();
+
+ /* Handle any termination request if any */
+ ProcessSlotSyncInterrupts(wrconn);
```
ProcessSlotSyncInterrupts() also has CHECK_FOR_INTERRUPTS(), so no need to call.
07. wait_for_primary_slot_catchup
```
+ /*
+ * XXX: Is waiting for 2 seconds before retrying enough or more or
+ * less?
+ */
+ rc = WaitLatch(MyLatch,
+ WL_LATCH_SET | WL_TIMEOUT | WL_POSTMASTER_DEATH,
+ 2000L,
+ WAIT_EVENT_REPL_SLOTSYNC_PRIMARY_CATCHUP);
+
+ ResetLatch(MyLatch);
+
+ /* Emergency bailout if postmaster has died */
+ if (rc & WL_POSTMASTER_DEATH)
+ proc_exit(1);
```
Is there any reasons not to use WL_EXIT_ON_PM_DEATH event? If not, you can use.
08. synchronize_slots
```
+ SpinLockAcquire(&WalRcv->mutex);
+ if (!WalRcv ||
+ (WalRcv->slotname[0] == '\0') ||
+ XLogRecPtrIsInvalid(WalRcv->latestWalEnd))
+ {
...
```
Assuming that WalRcv is still NULL. In this case, does the first SpinLockAcquire()
lead a segmentation fault?
09. synchronize_slots
```
+ elog(DEBUG2, "slot sync worker's query:%s \n", s.data);
```
The query is not dynamical one, so I think no need to print even if the debug
mode.
10. synchronize_one_slot
IIUC, this function can synchronize slots even if the used plugin on primary is
not installed on the secondary server. If the slot is created by the slotsync
worker, users will recognize it after the server is promoted and the decode is
starting. I felt it is not good specification. Can we detect in the validation
phase?
~~~~~
not the source code
11.
I tested the typical case - promoting a publisher from a below diagram.
A physical replication slot "physical" was specified as standby_slot_names.
```
node A (primary) --> node B (secondary)
|
|
node C (subscriber)
```
And after the promoting, below lines were periodically output on logfiles for
node B and C.
```
WARNING: replication slot "physical" specified in parameter "standby_slot_names" does not exist, ignoring
```
Do you have idea to suppress the warning? IIUC it is a normal behavior of the
walsender so that we cannot avoid the periodical outputs.
The steps of the test was as follows:
1. stop the node A via pg_ctl stop
2. promota the node B via pg_ctl promote
3. change the connection string of the subscription via ALTER SUBSCRIPTION ... CONNECTION ...
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
view thread (4+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: RE: Synchronizing slots from primary to standby
In-Reply-To: <TY3PR01MB98893274D5A4FD4F86CC04A0F595A@TY3PR01MB9889.jpnprd01.prod.outlook.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox