public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v1 2/8] code: s/master/primary/
37+ messages / 5 participants
[nested] [flat]
* [PATCH v1 2/8] code: s/master/primary/
@ 2020-06-14 21:05 Andres Freund <[email protected]>
0 siblings, 0 replies; 37+ messages in thread
From: Andres Freund @ 2020-06-14 21:05 UTC (permalink / raw)
Also changed "in the primary" to "on the primary", and added a few
"the" before "primary".
Author:
Reviewed-By:
Discussion: https://postgr.es/m/
Backpatch:
---
src/include/access/xlog.h | 4 +-
src/include/tcop/utility.h | 2 +-
src/include/utils/guc_tables.h | 2 +-
src/backend/access/common/bufmask.c | 4 +-
src/backend/access/gist/gistxlog.c | 2 +-
src/backend/access/heap/heapam.c | 12 ++--
src/backend/access/heap/pruneheap.c | 2 +-
src/backend/access/nbtree/README | 2 +-
src/backend/access/nbtree/nbtxlog.c | 2 +-
src/backend/access/transam/commit_ts.c | 12 ++--
src/backend/access/transam/xlog.c | 56 +++++++++----------
src/backend/access/transam/xlogutils.c | 6 +-
src/backend/catalog/namespace.c | 2 +-
src/backend/commands/tablecmds.c | 2 +-
src/backend/postmaster/postmaster.c | 4 +-
src/backend/replication/README | 6 +-
src/backend/replication/basebackup.c | 2 +-
src/backend/replication/logical/worker.c | 4 +-
src/backend/replication/walreceiver.c | 32 +++++------
src/backend/replication/walsender.c | 8 +--
src/backend/storage/ipc/procarray.c | 20 +++----
src/backend/storage/ipc/standby.c | 2 +-
src/backend/storage/lmgr/README | 2 +-
src/backend/storage/page/README | 2 +-
src/backend/utils/misc/guc.c | 8 +--
src/backend/utils/misc/postgresql.conf.sample | 8 +--
src/bin/pg_basebackup/pg_recvlogical.c | 2 +-
src/bin/pg_basebackup/receivelog.c | 4 +-
src/bin/pg_rewind/copy_fetch.c | 2 +-
src/bin/pg_rewind/filemap.c | 2 +-
src/bin/pg_rewind/parsexlog.c | 2 +-
31 files changed, 110 insertions(+), 110 deletions(-)
diff --git a/src/include/access/xlog.h b/src/include/access/xlog.h
index e917dfe92d8..afbfca6be86 100644
--- a/src/include/access/xlog.h
+++ b/src/include/access/xlog.h
@@ -50,7 +50,7 @@ extern bool InRecovery;
*
* In INITIALIZED state, we've run InitRecoveryTransactionEnvironment, but
* we haven't yet processed a RUNNING_XACTS or shutdown-checkpoint WAL record
- * to initialize our master-transaction tracking system.
+ * to initialize our primary-transaction tracking system.
*
* When the transaction tracking is initialized, we enter the SNAPSHOT_PENDING
* state. The tracked information might still be incomplete, so we can't allow
@@ -58,7 +58,7 @@ extern bool InRecovery;
* appropriate.
*
* In SNAPSHOT_READY mode, we have full knowledge of transactions that are
- * (or were) running in the master at the current WAL location. Snapshots
+ * (or were) running on the primary at the current WAL location. Snapshots
* can be taken, and read-only queries can be run.
*/
typedef enum
diff --git a/src/include/tcop/utility.h b/src/include/tcop/utility.h
index 4aec19a0087..9594856c88a 100644
--- a/src/include/tcop/utility.h
+++ b/src/include/tcop/utility.h
@@ -51,7 +51,7 @@ typedef struct AlterTableUtilityContext
*
* COMMAND_OK_IN_RECOVERY means that the command is permissible even when in
* recovery. It can't write WAL, nor can it do things that would imperil
- * replay of future WAL received from the master.
+ * replay of future WAL received from the primary.
*/
#define COMMAND_OK_IN_READ_ONLY_TXN 0x0001
#define COMMAND_OK_IN_PARALLEL_MODE 0x0002
diff --git a/src/include/utils/guc_tables.h b/src/include/utils/guc_tables.h
index 454c2df4878..04431d0eb25 100644
--- a/src/include/utils/guc_tables.h
+++ b/src/include/utils/guc_tables.h
@@ -73,7 +73,7 @@ enum config_group
WAL_RECOVERY_TARGET,
REPLICATION,
REPLICATION_SENDING,
- REPLICATION_MASTER,
+ REPLICATION_PRIMARY,
REPLICATION_STANDBY,
REPLICATION_SUBSCRIBERS,
QUERY_TUNING,
diff --git a/src/backend/access/common/bufmask.c b/src/backend/access/common/bufmask.c
index 8dcc747b94a..4bdb1848ad2 100644
--- a/src/backend/access/common/bufmask.c
+++ b/src/backend/access/common/bufmask.c
@@ -88,8 +88,8 @@ mask_unused_space(Page page)
/*
* mask_lp_flags
*
- * In some index AMs, line pointer flags can be modified in master without
- * emitting any WAL record.
+ * In some index AMs, line pointer flags can be modified on the primary
+ * without emitting any WAL record.
*/
void
mask_lp_flags(Page page)
diff --git a/src/backend/access/gist/gistxlog.c b/src/backend/access/gist/gistxlog.c
index b60dba052fa..3f0effd5e42 100644
--- a/src/backend/access/gist/gistxlog.c
+++ b/src/backend/access/gist/gistxlog.c
@@ -391,7 +391,7 @@ gistRedoPageReuse(XLogReaderState *record)
* RecentGlobalXmin test in gistPageRecyclable() conceptually mirrors the
* pgxact->xmin > limitXmin test in GetConflictingVirtualXIDs().
* Consequently, one XID value achieves the same exclusion effect on
- * master and standby.
+ * primary and standby.
*/
if (InHotStandby)
{
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 537913d1bb3..7bd45703aa6 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -410,10 +410,10 @@ heapgetpage(TableScanDesc sscan, BlockNumber page)
* visible to everyone, we can skip the per-tuple visibility tests.
*
* Note: In hot standby, a tuple that's already visible to all
- * transactions in the master might still be invisible to a read-only
+ * transactions on the primary might still be invisible to a read-only
* transaction in the standby. We partly handle this problem by tracking
* the minimum xmin of visible tuples as the cut-off XID while marking a
- * page all-visible on master and WAL log that along with the visibility
+ * page all-visible on the primary and WAL log that along with the visibility
* map SET operation. In hot standby, we wait for (or abort) all
* transactions that can potentially may not see one or more tuples on the
* page. That's how index-only scans work fine in hot standby. A crucial
@@ -6889,7 +6889,7 @@ HeapTupleHeaderAdvanceLatestRemovedXid(HeapTupleHeader tuple,
* updated/deleted by the inserting transaction.
*
* Look for a committed hint bit, or if no xmin bit is set, check clog.
- * This needs to work on both master and standby, where it is used to
+ * This needs to work on both primary and standby, where it is used to
* assess btree delete records.
*/
if (HeapTupleHeaderXminCommitted(tuple) ||
@@ -6951,9 +6951,9 @@ xid_horizon_prefetch_buffer(Relation rel,
* tuples being deleted.
*
* We used to do this during recovery rather than on the primary, but that
- * approach now appears inferior. It meant that the master could generate
+ * approach now appears inferior. It meant that the primary could generate
* a lot of work for the standby without any back-pressure to slow down the
- * master, and it required the standby to have reached consistency, whereas
+ * primary, and it required the standby to have reached consistency, whereas
* we want to have correct information available even before that point.
*
* It's possible for this to generate a fair amount of I/O, since we may be
@@ -8943,7 +8943,7 @@ heap_mask(char *pagedata, BlockNumber blkno)
*
* During redo, heap_xlog_insert() sets t_ctid to current block
* number and self offset number. It doesn't care about any
- * speculative insertions in master. Hence, we set t_ctid to
+ * speculative insertions on the primary. Hence, we set t_ctid to
* current block number and self offset number to ignore any
* inconsistency.
*/
diff --git a/src/backend/access/heap/pruneheap.c b/src/backend/access/heap/pruneheap.c
index 1794cfd8d9a..256df4de105 100644
--- a/src/backend/access/heap/pruneheap.c
+++ b/src/backend/access/heap/pruneheap.c
@@ -78,7 +78,7 @@ heap_page_prune_opt(Relation relation, Buffer buffer)
/*
* We can't write WAL in recovery mode, so there's no point trying to
- * clean the page. The master will likely issue a cleaning WAL record soon
+ * clean the page. The primary will likely issue a cleaning WAL record soon
* anyway, so this is no particular loss.
*/
if (RecoveryInProgress())
diff --git a/src/backend/access/nbtree/README b/src/backend/access/nbtree/README
index 216d419841c..32ad9e339a2 100644
--- a/src/backend/access/nbtree/README
+++ b/src/backend/access/nbtree/README
@@ -574,7 +574,7 @@ writers that insert on to the page being deleted.)
During recovery all index scans start with ignore_killed_tuples = false
and we never set kill_prior_tuple. We do this because the oldest xmin
-on the standby server can be older than the oldest xmin on the master
+on the standby server can be older than the oldest xmin on the primary
server, which means tuples can be marked LP_DEAD even when they are
still visible on the standby. We don't WAL log tuple LP_DEAD bits, but
they can still appear in the standby because of full page writes. So
diff --git a/src/backend/access/nbtree/nbtxlog.c b/src/backend/access/nbtree/nbtxlog.c
index 87a8612c28c..3c89a868836 100644
--- a/src/backend/access/nbtree/nbtxlog.c
+++ b/src/backend/access/nbtree/nbtxlog.c
@@ -931,7 +931,7 @@ btree_xlog_reuse_page(XLogReaderState *record)
* RecentGlobalXmin test in _bt_page_recyclable() conceptually mirrors the
* pgxact->xmin > limitXmin test in GetConflictingVirtualXIDs().
* Consequently, one XID value achieves the same exclusion effect on
- * master and standby.
+ * primary and standby.
*/
if (InHotStandby)
{
diff --git a/src/backend/access/transam/commit_ts.c b/src/backend/access/transam/commit_ts.c
index 9cdb1364359..182e5391f7b 100644
--- a/src/backend/access/transam/commit_ts.c
+++ b/src/backend/access/transam/commit_ts.c
@@ -392,7 +392,7 @@ error_commit_ts_disabled(void)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("could not get commit timestamp data"),
RecoveryInProgress() ?
- errhint("Make sure the configuration parameter \"%s\" is set on the master server.",
+ errhint("Make sure the configuration parameter \"%s\" is set on the primary server.",
"track_commit_timestamp") :
errhint("Make sure the configuration parameter \"%s\" is set.",
"track_commit_timestamp")));
@@ -592,12 +592,12 @@ CommitTsParameterChange(bool newvalue, bool oldvalue)
{
/*
* If the commit_ts module is disabled in this server and we get word from
- * the master server that it is enabled there, activate it so that we can
+ * the primary server that it is enabled there, activate it so that we can
* replay future WAL records involving it; also mark it as active on
* pg_control. If the old value was already set, we already did this, so
* don't do anything.
*
- * If the module is disabled in the master, disable it here too, unless
+ * If the module is disabled in the primary, disable it here too, unless
* the module is enabled locally.
*
* Note this only runs in the recovery process, so an unlocked read is
@@ -616,12 +616,12 @@ CommitTsParameterChange(bool newvalue, bool oldvalue)
* Activate this module whenever necessary.
* This must happen during postmaster or standalone-backend startup,
* or during WAL replay anytime the track_commit_timestamp setting is
- * changed in the master.
+ * changed in the primary.
*
* The reason why this SLRU needs separate activation/deactivation functions is
* that it can be enabled/disabled during start and the activation/deactivation
- * on master is propagated to standby via replay. Other SLRUs don't have this
- * property and they can be just initialized during normal startup.
+ * on the primary is propagated to the standby via replay. Other SLRUs don't
+ * have this property and they can be just initialized during normal startup.
*
* This is in charge of creating the currently active segment, if it's not
* already there. The reason for this is that the server might have been
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 55cac186dc7..2e07ca00774 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -273,7 +273,7 @@ static bool restoredFromArchive = false;
/* Buffers dedicated to consistency checks of size BLCKSZ */
static char *replay_image_masked = NULL;
-static char *master_image_masked = NULL;
+static char *primary_image_masked = NULL;
/* options formerly taken from recovery.conf for archive recovery */
char *recoveryRestoreCommand = NULL;
@@ -782,7 +782,7 @@ typedef enum
XLOG_FROM_ANY = 0, /* request to read WAL from any source */
XLOG_FROM_ARCHIVE, /* restored using restore_command */
XLOG_FROM_PG_WAL, /* existing file in pg_wal */
- XLOG_FROM_STREAM /* streamed from master */
+ XLOG_FROM_STREAM /* streamed from primary */
} XLogSource;
/* human-readable names for XLogSources, for debugging output */
@@ -1476,21 +1476,21 @@ checkXLogConsistency(XLogReaderState *record)
* page here, a local buffer is fine to hold its contents and a mask
* can be directly applied on it.
*/
- if (!RestoreBlockImage(record, block_id, master_image_masked))
+ if (!RestoreBlockImage(record, block_id, primary_image_masked))
elog(ERROR, "failed to restore block image");
/*
- * If masking function is defined, mask both the master and replay
+ * If masking function is defined, mask both the primary and replay
* images
*/
if (RmgrTable[rmid].rm_mask != NULL)
{
RmgrTable[rmid].rm_mask(replay_image_masked, blkno);
- RmgrTable[rmid].rm_mask(master_image_masked, blkno);
+ RmgrTable[rmid].rm_mask(primary_image_masked, blkno);
}
- /* Time to compare the master and replay images. */
- if (memcmp(replay_image_masked, master_image_masked, BLCKSZ) != 0)
+ /* Time to compare the primary and replay images. */
+ if (memcmp(replay_image_masked, primary_image_masked, BLCKSZ) != 0)
{
elog(FATAL,
"inconsistent page found, rel %u/%u/%u, forknum %u, blkno %u",
@@ -2299,7 +2299,7 @@ CalculateCheckpointSegments(void)
* a) we keep WAL for only one checkpoint cycle (prior to PG11 we kept
* WAL for two checkpoint cycles to allow us to recover from the
* secondary checkpoint if the first checkpoint failed, though we
- * only did this on the master anyway, not on standby. Keeping just
+ * only did this on the primary anyway, not on standby. Keeping just
* one checkpoint simplifies processing and reduces disk space in
* many smaller databases.)
* b) during checkpoint, we consume checkpoint_completion_target *
@@ -3768,7 +3768,7 @@ XLogFileReadAnyTLI(XLogSegNo segno, int emode, XLogSource source)
* however, unless we actually find a valid segment. That way if there is
* neither a timeline history file nor a WAL segment in the archive, and
* streaming replication is set up, we'll read the timeline history file
- * streamed from the master when we start streaming, instead of recovering
+ * streamed from the primary when we start streaming, instead of recovering
* with a dummy history generated here.
*/
if (expectedTLEs)
@@ -6055,7 +6055,7 @@ SetRecoveryPause(bool recoveryPause)
/*
* When recovery_min_apply_delay is set, we wait long enough to make sure
- * certain record types are applied at least that interval behind the master.
+ * certain record types are applied at least that interval behind the primary.
*
* Returns true if we waited.
*
@@ -6237,7 +6237,7 @@ do { \
if ((currValue) < (minValue)) \
ereport(ERROR, \
(errcode(ERRCODE_INVALID_PARAMETER_VALUE), \
- errmsg("hot standby is not possible because %s = %d is a lower setting than on the master server (its value was %d)", \
+ errmsg("hot standby is not possible because %s = %d is a lower setting than on the primary server (its value was %d)", \
param_name, \
currValue, \
minValue))); \
@@ -6273,8 +6273,8 @@ CheckRequiredParameterValues(void)
{
if (ControlFile->wal_level < WAL_LEVEL_REPLICA)
ereport(ERROR,
- (errmsg("hot standby is not possible because wal_level was not set to \"replica\" or higher on the master server"),
- errhint("Either set wal_level to \"replica\" on the master, or turn off hot_standby here.")));
+ (errmsg("hot standby is not possible because wal_level was not set to \"replica\" or higher on the primary server"),
+ errhint("Either set wal_level to \"replica\" on the primary, or turn off hot_standby here.")));
/* We ignore autovacuum_max_workers when we make this test. */
RecoveryRequiresIntParameter("max_connections",
@@ -6500,7 +6500,7 @@ StartupXLOG(void)
* alignment, whereas palloc() will provide MAXALIGN'd storage.
*/
replay_image_masked = (char *) palloc(BLCKSZ);
- master_image_masked = (char *) palloc(BLCKSZ);
+ primary_image_masked = (char *) palloc(BLCKSZ);
if (read_backup_label(&checkPointLoc, &backupEndRequired,
&backupFromStandby))
@@ -6629,7 +6629,7 @@ StartupXLOG(void)
* know how far we need to replay the WAL before we reach consistency.
* This can happen for example if a base backup is taken from a
* running server using an atomic filesystem snapshot, without calling
- * pg_start/stop_backup. Or if you just kill a running master server
+ * pg_start/stop_backup. Or if you just kill a running primary server
* and put it into archive recovery by creating a recovery signal
* file.
*
@@ -6827,7 +6827,7 @@ StartupXLOG(void)
* ourselves - the history file of the recovery target timeline covers all
* the previous timelines in the history too - a cascading standby server
* might be interested in them. Or, if you archive the WAL from this
- * server to a different archive than the master, it'd be good for all the
+ * server to a different archive than the primary, it'd be good for all the
* history files to get archived there after failover, so that you can use
* one of the old timelines as a PITR target. Timeline history files are
* small, so it's better to copy them unnecessarily than not copy them and
@@ -7063,7 +7063,7 @@ StartupXLOG(void)
/*
* If we're beginning at a shutdown checkpoint, we know that
- * nothing was running on the master at this point. So fake-up an
+ * nothing was running on the primary at this point. So fake-up an
* empty running-xacts record and use that here and now. Recover
* additional standby state for prepared transactions.
*/
@@ -7231,7 +7231,7 @@ StartupXLOG(void)
}
/*
- * If we've been asked to lag the master, wait on latch until
+ * If we've been asked to lag the primary, wait on latch until
* enough time has passed.
*/
if (recoveryApplyDelay(xlogreader))
@@ -7346,7 +7346,7 @@ StartupXLOG(void)
/*
* If rm_redo called XLogRequestWalReceiverReply, then we wake
* up the receiver so that it notices the updated
- * lastReplayedEndRecPtr and sends a reply to the master.
+ * lastReplayedEndRecPtr and sends a reply to the primary.
*/
if (doRequestWalReceiverReply)
{
@@ -9943,7 +9943,7 @@ xlog_redo(XLogReaderState *record)
/*
* If we see a shutdown checkpoint, we know that nothing was running
- * on the master at this point. So fake-up an empty running-xacts
+ * on the primary at this point. So fake-up an empty running-xacts
* record and use that here and now. Recover additional standby state
* for prepared transactions.
*/
@@ -10658,7 +10658,7 @@ do_pg_start_backup(const char *backupidstr, bool fast, TimeLineID *starttli_p,
"since last restartpoint"),
errhint("This means that the backup being taken on the standby "
"is corrupt and should not be used. "
- "Enable full_page_writes and run CHECKPOINT on the master, "
+ "Enable full_page_writes and run CHECKPOINT on the primary, "
"and then try an online backup again.")));
/*
@@ -10815,7 +10815,7 @@ do_pg_start_backup(const char *backupidstr, bool fast, TimeLineID *starttli_p,
appendStringInfo(labelfile, "BACKUP METHOD: %s\n",
exclusive ? "pg_start_backup" : "streamed");
appendStringInfo(labelfile, "BACKUP FROM: %s\n",
- backup_started_in_recovery ? "standby" : "master");
+ backup_started_in_recovery ? "standby" : "primary");
appendStringInfo(labelfile, "START TIME: %s\n", strfbuf);
appendStringInfo(labelfile, "LABEL: %s\n", backupidstr);
appendStringInfo(labelfile, "START TIMELINE: %u\n", starttli);
@@ -11250,7 +11250,7 @@ do_pg_stop_backup(char *labelfile, bool waitforarchive, TimeLineID *stoptli_p)
"during online backup"),
errhint("This means that the backup being taken on the standby "
"is corrupt and should not be used. "
- "Enable full_page_writes and run CHECKPOINT on the master, "
+ "Enable full_page_writes and run CHECKPOINT on the primary, "
"and then try an online backup again.")));
@@ -11932,7 +11932,7 @@ retry:
Assert(readFile != -1);
/*
- * If the current segment is being streamed from master, calculate how
+ * If the current segment is being streamed from the primary, calculate how
* much of the current page we have received already. We know the
* requested record has been received, but this is for the benefit of
* future calls, to allow quick exit at the top of this function.
@@ -11993,8 +11993,8 @@ retry:
* example, imagine a scenario where a streaming replica is started up,
* and replay reaches a record that's split across two WAL segments. The
* first page is only available locally, in pg_wal, because it's already
- * been recycled in the master. The second page, however, is not present
- * in pg_wal, and we should stream it from the master. There is a recycled
+ * been recycled on the primary. The second page, however, is not present
+ * in pg_wal, and we should stream it from the primary. There is a recycled
* WAL segment present in pg_wal, with garbage contents, however. We would
* read the first page from the local WAL segment, but when reading the
* second page, we would read the bogus, recycled, WAL segment. If we
@@ -12154,7 +12154,7 @@ WaitForWALToBecomeAvailable(XLogRecPtr RecPtr, bool randAccess,
* Failure while streaming. Most likely, we got here
* because streaming replication was terminated, or
* promotion was triggered. But we also get here if we
- * find an invalid record in the WAL streamed from master,
+ * find an invalid record in the WAL streamed from the primary,
* in which case something is seriously wrong. There's
* little chance that the problem will just go away, but
* PANIC is not good for availability either, especially
@@ -12515,7 +12515,7 @@ StartupRequestWalReceiverRestart(void)
* we're retrying the exact same record that we've tried previously, only
* complain the first time to keep the noise down. However, we only do when
* reading from pg_wal, because we don't expect any invalid records in archive
- * or in records streamed from master. Files in the archive should be complete,
+ * or in records streamed from the primary. Files in the archive should be complete,
* and we should never hit the end of WAL because we stop and wait for more WAL
* to arrive before replaying it.
*
diff --git a/src/backend/access/transam/xlogutils.c b/src/backend/access/transam/xlogutils.c
index 322b0e8ff5b..b2ca0cd4cf3 100644
--- a/src/backend/access/transam/xlogutils.c
+++ b/src/backend/access/transam/xlogutils.c
@@ -654,8 +654,8 @@ XLogTruncateRelation(RelFileNode rnode, ForkNumber forkNum,
*
* We care about timelines in xlogreader when we might be reading xlog
* generated prior to a promotion, either if we're currently a standby in
- * recovery or if we're a promoted master reading xlogs generated by the old
- * master before our promotion.
+ * recovery or if we're a promoted primary reading xlogs generated by the old
+ * primary before our promotion.
*
* wantPage must be set to the start address of the page to read and
* wantLength to the amount of the page that will be read, up to
@@ -878,7 +878,7 @@ read_local_xlog_page(XLogReaderState *state, XLogRecPtr targetPagePtr,
* we actually read the xlog page, we might still try to read from the
* old (now renamed) segment and fail. There's not much we can do
* about this, but it can only happen when we're a leaf of a cascading
- * standby whose master gets promoted while we're decoding, so a
+ * standby whose primary gets promoted while we're decoding, so a
* one-off ERROR isn't too bad.
*/
XLogReadDetermineTimeline(state, targetPagePtr, reqLen);
diff --git a/src/backend/catalog/namespace.c b/src/backend/catalog/namespace.c
index 2ec23016fe5..0152e3869ab 100644
--- a/src/backend/catalog/namespace.c
+++ b/src/backend/catalog/namespace.c
@@ -3969,7 +3969,7 @@ InitTempTableNamespace(void)
* Do not allow a Hot Standby session to make temp tables. Aside from
* problems with modifying the system catalogs, there is a naming
* conflict: pg_temp_N belongs to the session with BackendId N on the
- * master, not to a hot standby session with the same BackendId. We
+ * primary, not to a hot standby session with the same BackendId. We
* should not be able to get here anyway due to XactReadOnly checks, but
* let's just make real sure. Note that this also backstops various
* operations that allow XactReadOnly transactions to modify temp tables;
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 2ab02e01a02..fc7b375f485 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -3676,7 +3676,7 @@ AlterTableInternal(Oid relid, List *cmds, bool recurse)
* and does not travel through this section of code and cannot be combined with
* any of the subcommands given here.
*
- * Note that Hot Standby only knows about AccessExclusiveLocks on the master
+ * Note that Hot Standby only knows about AccessExclusiveLocks on the primary
* so any changes that might affect SELECTs running on standbys need to use
* AccessExclusiveLocks even if you think a lesser lock would do, unless you
* have a solution for that also.
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index b4d475bb0ba..dec02586c7f 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -1059,8 +1059,8 @@ PostmasterMain(int argc, char *argv[])
* only during a few moments during a standby promotion. However there is
* a race condition: if pg_ctl promote is executed and creates the files
* during a promotion, the files can stay around even after the server is
- * brought up to new master. Then, if new standby starts by using the
- * backup taken from that master, the files can exist at the server
+ * brought up to be the primary. Then, if a new standby starts by using the
+ * backup taken from the new primary, the files can exist at the server
* startup and should be removed in order to avoid an unexpected
* promotion.
*
diff --git a/src/backend/replication/README b/src/backend/replication/README
index 8ccdd86e74b..c608ec12097 100644
--- a/src/backend/replication/README
+++ b/src/backend/replication/README
@@ -53,11 +53,11 @@ it. Before that, however, startup process fills in WalRcvData->conninfo
and WalRcvData->slotname, and initializes the starting point in
WalRcvData->receiveStart.
-As walreceiver receives WAL from the master server, and writes and flushes
+As walreceiver receives WAL from the primary server, and writes and flushes
it to disk (in pg_wal), it updates WalRcvData->flushedUpto and signals
the startup process to know how far WAL replay can advance.
-Walreceiver sends information about replication progress to the master server
+Walreceiver sends information about replication progress to the primary server
whenever it either writes or flushes new WAL, or the specified interval elapses.
This is used for reporting purpose.
@@ -68,7 +68,7 @@ At shutdown, postmaster handles walsender processes differently from regular
backends. It waits for regular backends to die before writing the
shutdown checkpoint and terminating pgarch and other auxiliary processes, but
that's not desirable for walsenders, because we want the standby servers to
-receive all the WAL, including the shutdown checkpoint, before the master
+receive all the WAL, including the shutdown checkpoint, before the primary
is shut down. Therefore postmaster treats walsenders like the pgarch process,
and instructs them to terminate at PM_SHUTDOWN_2 phase, after all regular
backends have died and checkpointer has issued the shutdown checkpoint.
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 3b46bfe9ab0..02a344d7108 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -169,7 +169,7 @@ static const char *const excludeDirContents[] =
/*
* It is generally not useful to backup the contents of this directory
- * even if the intention is to restore to another master. See backup.sgml
+ * even if the intention is to restore to another primary. See backup.sgml
* for a more detailed description.
*/
"pg_replslot",
diff --git a/src/backend/replication/logical/worker.c b/src/backend/replication/logical/worker.c
index a752a1224d6..f90a896fc3e 100644
--- a/src/backend/replication/logical/worker.c
+++ b/src/backend/replication/logical/worker.c
@@ -1312,7 +1312,7 @@ apply_handle_truncate(StringInfo s)
}
/*
- * Even if we used CASCADE on the upstream master we explicitly default to
+ * Even if we used CASCADE on the upstream primary we explicitly default to
* replaying changes without further cascading. This might be later
* changeable with a user specified option.
*/
@@ -1661,7 +1661,7 @@ LogicalRepApplyLoop(XLogRecPtr last_received)
* from the server for more than wal_receiver_timeout / 2, ping
* the server. Also, if it's been longer than
* wal_receiver_status_interval since the last update we sent,
- * send a status update to the master anyway, to report any
+ * send a status update to the primary anyway, to report any
* progress in applying WAL.
*/
bool requestReply = false;
diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index d1ad75da87a..d5a9b568a68 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -357,8 +357,8 @@ WalReceiverMain(void)
/*
* Get any missing history files. We do this always, even when we're
* not interested in that timeline, so that if we're promoted to
- * become the master later on, we don't select the same timeline that
- * was already used in the current master. This isn't bullet-proof -
+ * become the primary later on, we don't select the same timeline that
+ * was already used in the current primary. This isn't bullet-proof -
* you'll need some external software to manage your cluster if you
* need to ensure that a unique timeline id is chosen in every case,
* but let's avoid the confusion of timeline id collisions where we
@@ -464,7 +464,7 @@ WalReceiverMain(void)
if (len > 0)
{
/*
- * Something was received from master, so reset
+ * Something was received from primary, so reset
* timeout
*/
last_recv_timestamp = GetCurrentTimestamp();
@@ -486,7 +486,7 @@ WalReceiverMain(void)
len = walrcv_receive(wrconn, &buf, &wait_fd);
}
- /* Let the master know that we received some data. */
+ /* Let the primary know that we received some data. */
XLogWalRcvSendReply(false, false);
/*
@@ -545,7 +545,7 @@ WalReceiverMain(void)
* wal_receiver_timeout / 2, ping the server. Also, if
* it's been longer than wal_receiver_status_interval
* since the last update we sent, send a status update to
- * the master anyway, to report any progress in applying
+ * the primary anyway, to report any progress in applying
* WAL.
*/
bool requestReply = false;
@@ -745,7 +745,7 @@ WalRcvFetchTimeLineHistoryFiles(TimeLineID first, TimeLineID last)
walrcv_readtimelinehistoryfile(wrconn, tli, &fname, &content, &len);
/*
- * Check that the filename on the master matches what we
+ * Check that the filename on the primary matches what we
* calculated ourselves. This is just a sanity check, it should
* always match.
*/
@@ -1034,7 +1034,7 @@ XLogWalRcvFlush(bool dying)
set_ps_display(activitymsg);
}
- /* Also let the master know that we made some progress */
+ /* Also let the primary know that we made some progress */
if (!dying)
{
XLogWalRcvSendReply(false, false);
@@ -1066,7 +1066,7 @@ XLogWalRcvSendReply(bool force, bool requestReply)
TimestampTz now;
/*
- * If the user doesn't want status to be reported to the master, be sure
+ * If the user doesn't want status to be reported to the primary, be sure
* to exit before doing anything at all.
*/
if (!force && wal_receiver_status_interval <= 0)
@@ -1080,7 +1080,7 @@ XLogWalRcvSendReply(bool force, bool requestReply)
* sent without taking any lock, but the apply position requires a spin
* lock, so we don't check that unless something else has changed or 10
* seconds have passed. This means that the apply WAL location will
- * appear, from the master's point of view, to lag slightly, but since
+ * appear, from the primary's point of view, to lag slightly, but since
* this is only for reporting purposes and only on idle systems, that's
* probably OK.
*/
@@ -1138,14 +1138,14 @@ XLogWalRcvSendHSFeedback(bool immed)
static TimestampTz sendTime = 0;
/* initially true so we always send at least one feedback message */
- static bool master_has_standby_xmin = true;
+ static bool primary_has_standby_xmin = true;
/*
- * If the user doesn't want status to be reported to the master, be sure
+ * If the user doesn't want status to be reported to the primary, be sure
* to exit before doing anything at all.
*/
if ((wal_receiver_status_interval <= 0 || !hot_standby_feedback) &&
- !master_has_standby_xmin)
+ !primary_has_standby_xmin)
return;
/* Get current timestamp. */
@@ -1168,7 +1168,7 @@ XLogWalRcvSendHSFeedback(bool immed)
* calls.
*
* Bailing out here also ensures that we don't send feedback until we've
- * read our own replication slot state, so we don't tell the master to
+ * read our own replication slot state, so we don't tell the primary to
* discard needed xmin or catalog_xmin from any slots that may exist on
* this replica.
*/
@@ -1230,9 +1230,9 @@ XLogWalRcvSendHSFeedback(bool immed)
pq_sendint32(&reply_message, catalog_xmin_epoch);
walrcv_send(wrconn, reply_message.data, reply_message.len);
if (TransactionIdIsValid(xmin) || TransactionIdIsValid(catalog_xmin))
- master_has_standby_xmin = true;
+ primary_has_standby_xmin = true;
else
- master_has_standby_xmin = false;
+ primary_has_standby_xmin = false;
}
/*
@@ -1291,7 +1291,7 @@ ProcessWalSndrMessage(XLogRecPtr walEnd, TimestampTz sendTime)
*
* This is called by the startup process whenever interesting xlog records
* are applied, so that walreceiver can check if it needs to send an apply
- * notification back to the master which may be waiting in a COMMIT with
+ * notification back to the primary which may be waiting in a COMMIT with
* synchronous_commit = remote_apply.
*/
void
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
index e2477c47e0a..f66acb87206 100644
--- a/src/backend/replication/walsender.c
+++ b/src/backend/replication/walsender.c
@@ -2628,14 +2628,14 @@ XLogSendPhysical(void)
else
{
/*
- * Streaming the current timeline on a master.
+ * Streaming the current timeline on a primary.
*
* Attempt to send all data that's already been written out and
* fsync'd to disk. We cannot go further than what's been written out
* given the current implementation of WALRead(). And in any case
* it's unsafe to send WAL that is not securely down to disk on the
- * master: if the master subsequently crashes and restarts, standbys
- * must not have applied any WAL that got lost on the master.
+ * primary: if the primary subsequently crashes and restarts, standbys
+ * must not have applied any WAL that got lost on the primary.
*/
SendRqstPtr = GetFlushRecPtr();
}
@@ -2672,7 +2672,7 @@ XLogSendPhysical(void)
*
* Note: We might already have sent WAL > sendTimeLineValidUpto. The
* startup process will normally replay all WAL that has been received
- * from the master, before promoting, but if the WAL streaming is
+ * from the primary, before promoting, but if the WAL streaming is
* terminated at a WAL page boundary, the valid portion of the timeline
* might end in the middle of a WAL record. We might've already sent the
* first half of that partial WAL record to the cascading standby, so that
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index 3c2b369615f..b4485335644 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -18,7 +18,7 @@
* at need by checking for pid == 0.
*
* During hot standby, we also keep a list of XIDs representing transactions
- * that are known to be running in the master (or more precisely, were running
+ * that are known to be running on the primary (or more precisely, were running
* as of the current point in the WAL stream). This list is kept in the
* KnownAssignedXids array, and is updated by watching the sequence of
* arriving XIDs. This is necessary because if we leave those XIDs out of
@@ -27,7 +27,7 @@
* array represents standby processes, which by definition are not running
* transactions that have XIDs.
*
- * It is perhaps possible for a backend on the master to terminate without
+ * It is perhaps possible for a backend on the primary to terminate without
* writing an abort record for its transaction. While that shouldn't really
* happen, it would tie up KnownAssignedXids indefinitely, so we protect
* ourselves by pruning the array when a valid list of running XIDs arrives.
@@ -651,7 +651,7 @@ ProcArrayInitRecovery(TransactionId initializedUptoXID)
* Normal case is to go all the way to Ready straight away, though there
* are atypical cases where we need to take it in steps.
*
- * Use the data about running transactions on master to create the initial
+ * Use the data about running transactions on the primary to create the initial
* state of KnownAssignedXids. We also use these records to regularly prune
* KnownAssignedXids because we know it is possible that some transactions
* with FATAL errors fail to write abort records, which could cause eventual
@@ -969,7 +969,7 @@ ProcArrayApplyXidAssignment(TransactionId topxid,
* We can find this out cheaply too.
*
* 3. In Hot Standby mode, we must search the KnownAssignedXids list to see
- * if the Xid is running on the master.
+ * if the Xid is running on the primary.
*
* 4. Search the SubTrans tree to find the Xid's topmost parent, and then see
* if that is running according to PGXACT or KnownAssignedXids. This is the
@@ -1198,7 +1198,7 @@ TransactionIdIsInProgress(TransactionId xid)
* TransactionIdIsActive -- is xid the top-level XID of an active backend?
*
* This differs from TransactionIdIsInProgress in that it ignores prepared
- * transactions, as well as transactions running on the master if we're in
+ * transactions, as well as transactions running on the primary if we're in
* hot standby. Also, we ignore subtransactions since that's not needed
* for current uses.
*/
@@ -1289,7 +1289,7 @@ TransactionIdIsActive(TransactionId xid)
* Nonetheless it is safe to vacuum a table in the current database with the
* first result. There are also replication-related effects: a walsender
* process can set its xmin based on transactions that are no longer running
- * in the master but are still being replayed on the standby, thus possibly
+ * on the primary but are still being replayed on the standby, thus possibly
* making the GetOldestXmin reading go backwards. In this case there is a
* possibility that we lose data that the standby would like to have, but
* unless the standby uses a replication slot to make its xmin persistent
@@ -1404,7 +1404,7 @@ GetOldestXmin(Relation rel, int flags)
*
* vacuum_defer_cleanup_age provides some additional "slop" for the
* benefit of hot standby queries on standby servers. This is quick
- * and dirty, and perhaps not all that useful unless the master has a
+ * and dirty, and perhaps not all that useful unless the primary has a
* predictable transaction rate, but it offers some protection when
* there's no walsender connection. Note that we are assuming
* vacuum_defer_cleanup_age isn't large enough to cause wraparound ---
@@ -3244,7 +3244,7 @@ DisplayXidCache(void)
/*
* In Hot Standby mode, we maintain a list of transactions that are (or were)
- * running in the master at the current point in WAL. These XIDs must be
+ * running on the primary at the current point in WAL. These XIDs must be
* treated as running by standby transactions, even though they are not in
* the standby server's PGXACT array.
*
@@ -3264,7 +3264,7 @@ DisplayXidCache(void)
* links are *not* maintained (which does not affect visibility).
*
* We have room in KnownAssignedXids and in snapshots to hold maxProcs *
- * (1 + PGPROC_MAX_CACHED_SUBXIDS) XIDs, so every master transaction must
+ * (1 + PGPROC_MAX_CACHED_SUBXIDS) XIDs, so every primary transaction must
* report its subtransaction XIDs in a WAL XLOG_XACT_ASSIGNMENT record at
* least every PGPROC_MAX_CACHED_SUBXIDS. When we receive one of these
* records, we mark the subXIDs as children of the top XID in pg_subtrans,
@@ -3439,7 +3439,7 @@ ExpireOldKnownAssignedTransactionIds(TransactionId xid)
* order, to be exact --- to allow binary search for specific XIDs. Note:
* in general TransactionIdPrecedes would not provide a total order, but
* we know that the entries present at any instant should not extend across
- * a large enough fraction of XID space to wrap around (the master would
+ * a large enough fraction of XID space to wrap around (the primary would
* shut down for fear of XID wrap long before that happens). So it's OK to
* use TransactionIdPrecedes as a binary-search comparator.
*
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index 9e0d5ec257f..f5229839cfc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -61,7 +61,7 @@ typedef struct RecoveryLockListsEntry
/*
* InitRecoveryTransactionEnvironment
- * Initialize tracking of in-progress transactions in master
+ * Initialize tracking of our primary's in-progress transactions.
*
* We need to issue shared invalidations and hold locks. Holding locks
* means others may want to wait on us, so we need to make a lock table
diff --git a/src/backend/storage/lmgr/README b/src/backend/storage/lmgr/README
index 13eb1cc785a..c96cc7b7c5f 100644
--- a/src/backend/storage/lmgr/README
+++ b/src/backend/storage/lmgr/README
@@ -725,7 +725,7 @@ Deadlocks involving AccessExclusiveLocks are not possible, so we need
not be concerned that a user initiated deadlock can prevent recovery from
progressing.
-AccessExclusiveLocks on the primary or master node generate WAL records
+AccessExclusiveLocks on the primary node generate WAL records
that are then applied by the Startup process. Locks are released at end
of transaction just as they are in normal processing. These locks are
held by the Startup process, acting as a proxy for the backends that
diff --git a/src/backend/storage/page/README b/src/backend/storage/page/README
index 4e45bd92abc..e30d7ac59ad 100644
--- a/src/backend/storage/page/README
+++ b/src/backend/storage/page/README
@@ -61,4 +61,4 @@ recovery must not dirty the page if the buffer is not already dirty, when
checksums are enabled. Systems in Hot-Standby mode may benefit from hint bits
being set, but with checksums enabled, a page cannot be dirtied after setting a
hint bit (due to the torn page risk). So, it must wait for full-page images
-containing the hint bit updates to arrive from the master.
+containing the hint bit updates to arrive from the primary.
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 75fc6f11d6a..1359caa08f6 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -708,8 +708,8 @@ const char *const config_group_names[] =
gettext_noop("Replication"),
/* REPLICATION_SENDING */
gettext_noop("Replication / Sending Servers"),
- /* REPLICATION_MASTER */
- gettext_noop("Replication / Master Server"),
+ /* REPLICATION_PRIMARY */
+ gettext_noop("Replication / Primary Server"),
/* REPLICATION_STANDBY */
gettext_noop("Replication / Standby Servers"),
/* REPLICATION_SUBSCRIBERS */
@@ -2549,7 +2549,7 @@ static struct config_int ConfigureNamesInt[] =
},
{
- {"vacuum_defer_cleanup_age", PGC_SIGHUP, REPLICATION_MASTER,
+ {"vacuum_defer_cleanup_age", PGC_SIGHUP, REPLICATION_PRIMARY,
gettext_noop("Number of transactions by which VACUUM and HOT cleanup should be deferred, if any."),
NULL
},
@@ -4292,7 +4292,7 @@ static struct config_string ConfigureNamesString[] =
},
{
- {"synchronous_standby_names", PGC_SIGHUP, REPLICATION_MASTER,
+ {"synchronous_standby_names", PGC_SIGHUP, REPLICATION_PRIMARY,
gettext_noop("Number of synchronous standbys and list of names of potential synchronous ones."),
NULL,
GUC_LIST_INPUT
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index 3a25287a391..e6649de649b 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -284,7 +284,7 @@
# - Sending Servers -
-# Set these on the master and on any standby that will send replication data.
+# Set these on the primary and on any standby that will send replication data.
#max_wal_senders = 10 # max number of walsender processes
# (change requires restart)
@@ -297,7 +297,7 @@
#track_commit_timestamp = off # collect timestamp of transaction commit
# (change requires restart)
-# - Master Server -
+# - Primary Server -
# These settings are ignored on a standby server.
@@ -309,7 +309,7 @@
# - Standby Servers -
-# These settings are ignored on a master server.
+# These settings are ignored on a primary server.
#primary_conninfo = '' # connection string to sending server
#primary_slot_name = '' # replication slot on sending server
@@ -329,7 +329,7 @@
#hot_standby_feedback = off # send info from standby to prevent
# query conflicts
#wal_receiver_timeout = 60s # time that receiver waits for
- # communication from master
+ # communication from primary
# in milliseconds; 0 disables
#wal_retrieve_retry_interval = 5s # time to wait before retrying to
# retrieve WAL after a failed attempt
diff --git a/src/bin/pg_basebackup/pg_recvlogical.c b/src/bin/pg_basebackup/pg_recvlogical.c
index cc8616844ba..a4e0d6aeb29 100644
--- a/src/bin/pg_basebackup/pg_recvlogical.c
+++ b/src/bin/pg_basebackup/pg_recvlogical.c
@@ -286,7 +286,7 @@ StreamLogicalLog(void)
}
/*
- * Potentially send a status message to the master
+ * Potentially send a status message to the primary.
*/
now = feGetCurrentTimestamp();
diff --git a/src/bin/pg_basebackup/receivelog.c b/src/bin/pg_basebackup/receivelog.c
index 62a342f77c9..d3f99d89c5c 100644
--- a/src/bin/pg_basebackup/receivelog.c
+++ b/src/bin/pg_basebackup/receivelog.c
@@ -417,7 +417,7 @@ CheckServerVersionForStreaming(PGconn *conn)
* race-y since a signal received while busy won't interrupt the wait.
*
* standby_message_timeout controls how often we send a message
- * back to the master letting it know our progress, in milliseconds.
+ * back to the primary letting it know our progress, in milliseconds.
* Zero means no messages are sent.
* This message will only contain the write location, and never
* flush or replay.
@@ -776,7 +776,7 @@ HandleCopyStream(PGconn *conn, StreamCtl *stream,
}
/*
- * Potentially send a status message to the master
+ * Potentially send a status message to the primary
*/
if (still_sending && stream->standby_message_timeout > 0 &&
feTimestampDifferenceExceeds(last_status, now,
diff --git a/src/bin/pg_rewind/copy_fetch.c b/src/bin/pg_rewind/copy_fetch.c
index 223c32628dd..1edab5f1867 100644
--- a/src/bin/pg_rewind/copy_fetch.c
+++ b/src/bin/pg_rewind/copy_fetch.c
@@ -76,7 +76,7 @@ recurse_dir(const char *datadir, const char *parentpath,
if (errno == ENOENT)
{
/*
- * File doesn't exist anymore. This is ok, if the new master
+ * File doesn't exist anymore. This is ok, if the new primary
* is running and the file was just removed. If it was a data
* file, there should be a WAL record of the removal. If it
* was something else, it couldn't have been anyway.
diff --git a/src/bin/pg_rewind/filemap.c b/src/bin/pg_rewind/filemap.c
index 36a2d623415..1879257b66a 100644
--- a/src/bin/pg_rewind/filemap.c
+++ b/src/bin/pg_rewind/filemap.c
@@ -62,7 +62,7 @@ static const char *excludeDirContents[] =
/*
* It is generally not useful to backup the contents of this directory
- * even if the intention is to restore to another master. See backup.sgml
+ * even if the intention is to restore to another primary. See backup.sgml
* for a more detailed description.
*/
"pg_replslot",
diff --git a/src/bin/pg_rewind/parsexlog.c b/src/bin/pg_rewind/parsexlog.c
index bc6f9769941..2325fb5d302 100644
--- a/src/bin/pg_rewind/parsexlog.c
+++ b/src/bin/pg_rewind/parsexlog.c
@@ -206,7 +206,7 @@ findLastCheckpoint(const char *datadir, XLogRecPtr forkptr, int tliIndex,
/*
* Check if it is a checkpoint record. This checkpoint record needs to
* be the latest checkpoint before WAL forked and not the checkpoint
- * where the master has been stopped to be rewinded.
+ * where the primary has been stopped to be rewinded.
*/
info = XLogRecGetInfo(xlogreader) & ~XLR_INFO_MASK;
if (searchptr < forkptr &&
--
2.25.0.114.g5b0ca878e0
--3w56e5bmtpe6xeaj
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v1-0003-code-s-master-leader.patch"
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: [BUG]: the walsender does not update its IO statistics until it exits
@ 2025-02-27 03:09 ` Michael Paquier <[email protected]>
2025-02-27 10:06 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Andres Freund <[email protected]>
2025-09-30 07:14 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
3 siblings, 2 replies; 37+ messages in thread
From: Michael Paquier @ 2025-02-27 03:09 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected]
On Wed, Feb 26, 2025 at 05:08:17AM -0500, Andres Freund wrote:
> I think it's also bad that we don't have a solution for 1), even just for
> normal connections. If a backend causes a lot of IO we might want to know
> about that long before the longrunning transaction commits.
>
> I suspect the right design here would be to have a generalized form of the
> timeout mechanism we have for 2).
>
> For that we'd need to make sure that pgstat_report_stat() can be safely called
> inside a transaction. The second part would be to redesign the
> IdleStatsUpdateTimeoutPending mechanism so it is triggered independent of
> idleness, without introducing unacceptable overhead - I think that's doable.
Agreed that something in the lines of non-transaction update of the
entries could be adapted in some cases, so +1 for the idea. I suspect
that there would be cases where a single stats kind should be able to
handle both transactional and non-transactional flush cases.
Splitting that across two stats kinds would lead to a lot of
duplication.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: [BUG]: the walsender does not update its IO statistics until it exits
2025-02-27 03:09 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
@ 2025-02-27 10:06 ` Andres Freund <[email protected]>
1 sibling, 0 replies; 37+ messages in thread
From: Andres Freund @ 2025-02-27 10:06 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected]
On 2025-02-27 12:09:46 +0900, Michael Paquier wrote:
> I suspect that there would be cases where a single stats kind should be able
> to handle both transactional and non-transactional flush cases. Splitting
> that across two stats kinds would lead to a lot of duplication.
Agreed. Table stats will be the prime case where that's important.
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: [BUG]: the walsender does not update its IO statistics until it exits
2025-02-27 03:09 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
@ 2025-09-30 07:14 ` Bertrand Drouvot <[email protected]>
2025-09-30 07:37 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
1 sibling, 1 reply; 37+ messages in thread
From: Bertrand Drouvot @ 2025-09-30 07:14 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; [email protected]
Hi,
On Thu, Feb 27, 2025 at 12:09:46PM +0900, Michael Paquier wrote:
> On Wed, Feb 26, 2025 at 05:08:17AM -0500, Andres Freund wrote:
> > I think it's also bad that we don't have a solution for 1), even just for
> > normal connections. If a backend causes a lot of IO we might want to know
> > about that long before the longrunning transaction commits.
> >
> > I suspect the right design here would be to have a generalized form of the
> > timeout mechanism we have for 2).
> >
> > For that we'd need to make sure that pgstat_report_stat() can be safely called
> > inside a transaction. The second part would be to redesign the
> > IdleStatsUpdateTimeoutPending mechanism so it is triggered independent of
> > idleness, without introducing unacceptable overhead - I think that's doable.
>
> Agreed that something in the lines of non-transaction update of the
> entries could be adapted in some cases, so +1 for the idea. I suspect
> that there would be cases where a single stats kind should be able to
> handle both transactional and non-transactional flush cases.
> Splitting that across two stats kinds would lead to a lot of
> duplication.
One option could be to use 2 pending lists for the variables stats and 2 flush
callbacks for fixed stats. Thoughts?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: [BUG]: the walsender does not update its IO statistics until it exits
2025-02-27 03:09 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-09-30 07:14 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
@ 2025-09-30 07:37 ` Michael Paquier <[email protected]>
2025-09-30 10:05 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Michael Paquier @ 2025-09-30 07:37 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: Andres Freund <[email protected]>; [email protected]
On Tue, Sep 30, 2025 at 07:14:14AM +0000, Bertrand Drouvot wrote:
> On Thu, Feb 27, 2025 at 12:09:46PM +0900, Michael Paquier wrote:
>> Agreed that something in the lines of non-transaction update of the
>> entries could be adapted in some cases, so +1 for the idea. I suspect
>> that there would be cases where a single stats kind should be able to
>> handle both transactional and non-transactional flush cases.
>> Splitting that across two stats kinds would lead to a lot of
>> duplication.
>
> One option could be to use 2 pending lists for the variables stats and 2 flush
> callbacks for fixed stats. Thoughts?
Hmm. I would have thought first about one pending area, and two
callbacks for the variable-sized stats, called with a different
timing because the stats to be flushed are the same aren't they? For
example, if we are in a long analytical query, we would flush the IO
stats periodically, reset the pending data, repeat/rinse periodically,
and do a last round when we are done with the query in postgres.c.
Do we really need a second callback by the way? It could be as well
the same flush callback, with an option to mark stats kinds that allow
a periodic flush. The trick is knowing where the new reports calls
should happen. The executor is the primary target area.
Or perhaps you think that the pending data of a stats kind could be
different if a kind allows transactional and non-transactional
flushes?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: [BUG]: the walsender does not update its IO statistics until it exits
2025-02-27 03:09 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-09-30 07:14 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-09-30 07:37 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
@ 2025-09-30 10:05 ` Bertrand Drouvot <[email protected]>
2025-09-30 22:43 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Bertrand Drouvot @ 2025-09-30 10:05 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; [email protected]
Hi,
On Tue, Sep 30, 2025 at 04:37:25PM +0900, Michael Paquier wrote:
> On Tue, Sep 30, 2025 at 07:14:14AM +0000, Bertrand Drouvot wrote:
> > On Thu, Feb 27, 2025 at 12:09:46PM +0900, Michael Paquier wrote:
> >> Agreed that something in the lines of non-transaction update of the
> >> entries could be adapted in some cases, so +1 for the idea. I suspect
> >> that there would be cases where a single stats kind should be able to
> >> handle both transactional and non-transactional flush cases.
> >> Splitting that across two stats kinds would lead to a lot of
> >> duplication.
> >
> > One option could be to use 2 pending lists for the variables stats and 2 flush
> > callbacks for fixed stats. Thoughts?
>
> Hmm. I would have thought first about one pending area, and two
> callbacks for the variable-sized stats, called with a different
> timing because the stats to be flushed are the same aren't they? For
> example, if we are in a long analytical query, we would flush the IO
> stats periodically, reset the pending data, repeat/rinse periodically,
> and do a last round when we are done with the query in postgres.c.
>
> Do we really need a second callback by the way? It could be as well
> the same flush callback, with an option to mark stats kinds that allow
> a periodic flush. The trick is knowing where the new reports calls
> should happen. The executor is the primary target area.
>
> Or perhaps you think that the pending data of a stats kind could be
> different if a kind allows transactional and non-transactional
> flushes?
Yeah that was my thought: one stats kind could have metrics that are transactional
and some metrics that are non-transactional. This could be possible for
both variable and fixed stats, that's why I was thinking about having
2 pending lists for the variables stats and 2 flush callbacks for fixed stats.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: [BUG]: the walsender does not update its IO statistics until it exits
2025-02-27 03:09 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-09-30 07:14 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-09-30 07:37 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-09-30 10:05 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
@ 2025-09-30 22:43 ` Michael Paquier <[email protected]>
2025-10-01 14:21 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Michael Paquier @ 2025-09-30 22:43 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: Andres Freund <[email protected]>; [email protected]
On Tue, Sep 30, 2025 at 10:05:43AM +0000, Bertrand Drouvot wrote:
> On Tue, Sep 30, 2025 at 04:37:25PM +0900, Michael Paquier wrote:
>> Or perhaps you think that the pending data of a stats kind could be
>> different if a kind allows transactional and non-transactional
>> flushes?
>
> Yeah that was my thought: one stats kind could have metrics that are transactional
> and some metrics that are non-transactional. This could be possible for
> both variable and fixed stats, that's why I was thinking about having
> 2 pending lists for the variables stats and 2 flush callbacks for fixed stats.
Okay. The first use case that comes into mind here is pgstat_io.c, to
offer periodic reports on analytics (please extend that to the backend
stats for WAL and I/O). In this case, it seems that it would be good
to know about all the stats fields, meaning that a single pending list
is OK. My feeling would be to reuse pgstat_report_stat() and plant a
new argument for the transactional state (or just a bits32 that works
along the force option) with the same threshold for reports, combined
with a new option to allow non-transactional reports (don't see a
point in forcing these and wait on locks, 1-min reports not happening
would not matter if an analytical query takes a few hours).
It would be better to determine a list of the stats we'd be
interesting in seeing updated without waiting for a query or a
transaction to finish, then design the needs around these
requirements, with a new thread to discuss the matter. The IO stats
are just the first case coming into mind.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: [BUG]: the walsender does not update its IO statistics until it exits
2025-02-27 03:09 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-09-30 07:14 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-09-30 07:37 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-09-30 10:05 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-09-30 22:43 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
@ 2025-10-01 14:21 ` Bertrand Drouvot <[email protected]>
0 siblings, 0 replies; 37+ messages in thread
From: Bertrand Drouvot @ 2025-10-01 14:21 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; [email protected]
Hi,
On Wed, Oct 01, 2025 at 07:43:31AM +0900, Michael Paquier wrote:
> On Tue, Sep 30, 2025 at 10:05:43AM +0000, Bertrand Drouvot wrote:
> > On Tue, Sep 30, 2025 at 04:37:25PM +0900, Michael Paquier wrote:
> >> Or perhaps you think that the pending data of a stats kind could be
> >> different if a kind allows transactional and non-transactional
> >> flushes?
> >
> > Yeah that was my thought: one stats kind could have metrics that are transactional
> > and some metrics that are non-transactional. This could be possible for
> > both variable and fixed stats, that's why I was thinking about having
> > 2 pending lists for the variables stats and 2 flush callbacks for fixed stats.
>
> Okay. The first use case that comes into mind here is pgstat_io.c, to
> offer periodic reports on analytics (please extend that to the backend
> stats for WAL and I/O). In this case, it seems that it would be good
> to know about all the stats fields, meaning that a single pending list
> is OK. My feeling would be to reuse pgstat_report_stat() and plant a
> new argument for the transactional state (or just a bits32 that works
> along the force option) with the same threshold for reports, combined
> with a new option to allow non-transactional reports (don't see a
> point in forcing these and wait on locks, 1-min reports not happening
> would not matter if an analytical query takes a few hours).
>
> It would be better to determine a list of the stats we'd be
> interesting in seeing updated without waiting for a query or a
> transaction to finish, then design the needs around these
> requirements, with a new thread to discuss the matter. The IO stats
> are just the first case coming into mind.
Yeah. Also for the relations stats we'd have a mix (for example there is no
need to wait for a transaction to finish to report it's related seq_scan if
any).
I'll work on a list and open a dedicated thread.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: [BUG]: the walsender does not update its IO statistics until it exits
@ 2025-03-10 00:23 ` Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
3 siblings, 1 reply; 37+ messages in thread
From: Michael Paquier @ 2025-03-10 00:23 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: [email protected]
On Mon, Mar 03, 2025 at 11:54:39AM +0000, Bertrand Drouvot wrote:
> So it does not look like what we're adding here can be seen as a primary bottleneck
> but that is probably worth implementing the "have_iostats" optimization attached.
>
> Also, while I did not measure any noticeable extra lag, given the fact that
> pgstat_flush_io() shows at about 5.5% and pgstat_flush_backend() at about 2.5%,
> that could still make sense to reduce the frequency of the flush calls, thoughts?
Okay. The number of reports really worry me anyway as proposed in the
patch. It's not really complicated to see dozens of pgstats calls in
a single millisecond in the WAL sender, even with some of the
regression tests. That's more present in the logirep scenarios, it
seems..
For example, here are some numbers based on some elog() calls planted
in walreceiver.c, looking at the logs of the TAP tests. Through a
single check-world, I am able to gather the following information:
- The location proposed by the patch leads to 680k stats reports,
in WalSndLoop() because the "Block if we have unsent data". Some
tests show quite some contention.
- A different location, in WalSndLoop() just before WalSndWait() leads
to 59k calls. And there's some contention in the logirep tests..
- I've spotted a third candidate which looks pretty solid, actually:
WalSndWaitForWal() before WalSndWait(). This leads to 2.9k reports in
the whole test suite, with much less contention in the reports. These
can still be rather frequent, up to ~50 calls per seconds, but that's
really less than the two others.
Stats data is useful as long as it is possible to get an idea of how
the system behaves, particularly with a steady workload. More
frequent reports are useful for spikey data detection, showing more
noise. Still, too many reports may cause the part gathering the
reports to become a bottleneck, while we want it to offer hints about
bottlenecks. So I would argue in favor of a more conservative choice
in the back branches than what the patch is proposing. Choice 3 i'm
quoting above is tempting by design: not too much, still frequent
enough to offer enough relevant information in the stats.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
@ 2025-03-10 14:52 ` Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Bertrand Drouvot @ 2025-03-10 14:52 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: [email protected]
Hi,
On Mon, Mar 10, 2025 at 09:23:50AM +0900, Michael Paquier wrote:
> On Mon, Mar 03, 2025 at 11:54:39AM +0000, Bertrand Drouvot wrote:
> > So it does not look like what we're adding here can be seen as a primary bottleneck
> > but that is probably worth implementing the "have_iostats" optimization attached.
> >
> > Also, while I did not measure any noticeable extra lag, given the fact that
> > pgstat_flush_io() shows at about 5.5% and pgstat_flush_backend() at about 2.5%,
> > that could still make sense to reduce the frequency of the flush calls, thoughts?
>
> - I've spotted a third candidate which looks pretty solid, actually:
> WalSndWaitForWal() before WalSndWait(). This leads to 2.9k reports in
> the whole test suite, with much less contention in the reports. These
> can still be rather frequent, up to ~50 calls per seconds, but that's
> really less than the two others.
>
> Stats data is useful as long as it is possible to get an idea of how
> the system behaves, particularly with a steady workload. More
> frequent reports are useful for spikey data detection, showing more
> noise. Still, too many reports may cause the part gathering the
> reports to become a bottleneck, while we want it to offer hints about
> bottlenecks. So I would argue in favor of a more conservative choice
> in the back branches than what the patch is proposing.
Yeah, fully agree. Anyway, having so many frequent stats reports makes little sense.
> Choice 3 i'm
> quoting above is tempting by design: not too much, still frequent
> enough to offer enough relevant information in the stats.
Yeah, I also agree that we should reduce the number of "reports". I'll look
at the third option.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
@ 2025-03-11 06:10 ` Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Bertrand Drouvot @ 2025-03-11 06:10 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: [email protected]
Hi,
On Mon, Mar 10, 2025 at 02:52:42PM +0000, Bertrand Drouvot wrote:
> Hi,
>
> On Mon, Mar 10, 2025 at 09:23:50AM +0900, Michael Paquier wrote:
> > On Mon, Mar 03, 2025 at 11:54:39AM +0000, Bertrand Drouvot wrote:
> > > So it does not look like what we're adding here can be seen as a primary bottleneck
> > > but that is probably worth implementing the "have_iostats" optimization attached.
> > >
> > > Also, while I did not measure any noticeable extra lag, given the fact that
> > > pgstat_flush_io() shows at about 5.5% and pgstat_flush_backend() at about 2.5%,
> > > that could still make sense to reduce the frequency of the flush calls, thoughts?
> >
> > - I've spotted a third candidate which looks pretty solid, actually:
> > WalSndWaitForWal() before WalSndWait(). This leads to 2.9k reports in
> > the whole test suite, with much less contention in the reports. These
> > can still be rather frequent, up to ~50 calls per seconds, but that's
> > really less than the two others.
> >
> > Stats data is useful as long as it is possible to get an idea of how
> > the system behaves, particularly with a steady workload. More
> > frequent reports are useful for spikey data detection, showing more
> > noise. Still, too many reports may cause the part gathering the
> > reports to become a bottleneck, while we want it to offer hints about
> > bottlenecks. So I would argue in favor of a more conservative choice
> > in the back branches than what the patch is proposing.
>
> Yeah, fully agree. Anyway, having so many frequent stats reports makes little sense.
>
> > Choice 3 i'm
> > quoting above is tempting by design: not too much, still frequent
> > enough to offer enough relevant information in the stats.
>
> Yeah, I also agree that we should reduce the number of "reports". I'll look
> at the third option.
WalSndWaitForWal() is being used only for logical walsender. So we'd need to
find another location for the physical walsender case. One option is to keep the
WalSndLoop() location and control the reports frequency.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
@ 2025-03-13 09:31 ` Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Bertrand Drouvot @ 2025-03-13 09:31 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: [email protected]
Hi,
On Tue, Mar 11, 2025 at 06:10:32AM +0000, Bertrand Drouvot wrote:
> WalSndWaitForWal() is being used only for logical walsender. So we'd need to
> find another location for the physical walsender case. One option is to keep the
> WalSndLoop() location and control the reports frequency.
I ended up with an idea in the same vein as your third one, but let's do it
in WalSndLoop() instead for both logical and physical walsenders. The idea
is to report the stats when the walsender is caught up or has pending data to
send. Also, we do flush only periodically (based on PGSTAT_MIN_INTERVAL).
Remarks/Questions:
1. maybe relying on PGSTAT_IDLE_INTERVAL would make more sense? In both case
PGSTAT_MIN_INTERVAL or PGSTAT_MIN_INTERVAL, I'm not sure there is a need to
update the related doc.
2. bonus point to make it here is that we don't need an extra call to
GetCurrentTimestamp(). We simply assign the one that is already done to "now".
3. add to use poll_query_until() has I've seen failures on the CI whith this
new approach. Also moving the test far away from the stats reset to to minimize
the risk of polling for too long.
With the attached in place, the number of times the stats are being flushed
reduce drastically but still seems enough to get an accurate idea of the walsender
IO activity. Thoughts?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
@ 2025-03-13 11:35 ` Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Xuneng Zhou @ 2025-03-13 11:35 UTC (permalink / raw)
To: pgsql-hackers
Sorry, forgot to cc this one too.
---------- Forwarded message ---------
发件人： Xuneng Zhou <[email protected]>
Date: 2025年3月13日周四 19:29
Subject: Re: [BUG]: the walsender does not update its IO statistics until
it exits
To: Bertrand Drouvot <[email protected]>
Hi,
Given that PGSTAT_MIN_INTERVAL is the go-to setting for stats flushes
* Unless called with 'force', pending stats updates are flushed happen once
* per PGSTAT_MIN_INTERVAL (1000ms). When not forced, stats flushes do not
* block on lock acquisition, except if stats updates have been pending for
* longer than PGSTAT_MAX_INTERVAL (60000ms).
*
* Whenever pending stats updates remain at the end of pgstat_report_stat()
a
* suggested idle timeout is returned. Currently this is always
* PGSTAT_IDLE_INTERVAL (10000ms). Callers can use the returned time to set
up
* a timeout after which to call pgstat_report_stat(true), but are not
* required to do so.
I am curious about the reason for this:
> 1. maybe relying on PGSTAT_IDLE_INTERVAL would make more sense? In both
> case
> PGSTAT_MIN_INTERVAL or PGSTAT_MIN_INTERVAL, I'm not sure there is a need to
> update the related doc.
>
>
PGSTAT_IDLE_INTERVAL seems to reduce the frequency even more.
>
> With the attached in place, the number of times the stats are being flushed
> reduce drastically but still seems enough to get an accurate idea of the
> walsender
> IO activity. Thoughts?
>
>
>
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
@ 2025-03-13 13:19 ` Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Bertrand Drouvot @ 2025-03-13 13:19 UTC (permalink / raw)
To: Xuneng Zhou <[email protected]>; +Cc: pgsql-hackers
Hi,
On Thu, Mar 13, 2025 at 07:35:24PM +0800, Xuneng Zhou wrote:
> Hi,
> Given that PGSTAT_MIN_INTERVAL is the go-to setting for stats flushes
> * Unless called with 'force', pending stats updates are flushed happen once
> * per PGSTAT_MIN_INTERVAL (1000ms). When not forced, stats flushes do not
> * block on lock acquisition, except if stats updates have been pending for
> * longer than PGSTAT_MAX_INTERVAL (60000ms).
> *
> * Whenever pending stats updates remain at the end of pgstat_report_stat()
> a
> * suggested idle timeout is returned. Currently this is always
> * PGSTAT_IDLE_INTERVAL (10000ms). Callers can use the returned time to set
> up
> * a timeout after which to call pgstat_report_stat(true), but are not
> * required to do so.
>
> I am curious about the reason for this:
Thanks for looking at it!
> > 1. maybe relying on PGSTAT_IDLE_INTERVAL would make more sense? In both
> > case
> > PGSTAT_MIN_INTERVAL or PGSTAT_MIN_INTERVAL, I'm not sure there is a need to
> > update the related doc.
> >
> >
> PGSTAT_IDLE_INTERVAL seems to reduce the frequency even more.
Yeah, I think that PGSTAT_MIN_INTERVAL is the one to use (that's why that's the
one the patch is using). I just mentioned PGSTAT_IDLE_INTERVAL as an open door
for conversation in case one prefers a "larger" frequency.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
@ 2025-03-18 11:14 ` Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Xuneng Zhou @ 2025-03-18 11:14 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: pgsql-hackers; Michael Paquier <[email protected]>; Andres Freund <[email protected]>
Hi,
I performed some tests using elog(no so sure whether this is the proper way
to do it) to monitor the new method. Here are the findings:
• With PGSTAT_MIN_INTERVAL set to 1000ms, the number of flush reports was
reduced to approximately 40–50 during the installcheck test suite.
• With PGSTAT_IDLE_INTERVAL set to 10000ms, the reports dropped to fewer
than 5.
• In contrast, the previous approach—flushing after every
WalSndKeepaliveIfNecessary()—resulted in roughly 50,000 flushes.
This reduction is significant, so the overhead from the flush reports is no
longer a concern. However, we still need to determine whether this
frequency is sufficient to capture the system’s state during periods of
high WAL activity. Based on my tests, using PGSTAT_MIN_INTERVAL seems to
provide a better balance than PGSTAT_IDLE_INTERVAL.
>
> > > 1. maybe relying on PGSTAT_IDLE_INTERVAL would make more sense? In both
> > > case
> > > PGSTAT_MIN_INTERVAL or PGSTAT_MIN_INTERVAL, I'm not sure there is a
> need to
> > > update the related doc.
> > >
> > >
> > PGSTAT_IDLE_INTERVAL seems to reduce the frequency even more.
>
> Yeah, I think that PGSTAT_MIN_INTERVAL is the one to use (that's why
> that's the
> one the patch is using). I just mentioned PGSTAT_IDLE_INTERVAL as an open
> door
> for conversation in case one prefers a "larger" frequency.
>
>
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
@ 2025-03-18 14:45 ` Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Bertrand Drouvot @ 2025-03-18 14:45 UTC (permalink / raw)
To: Xuneng Zhou <[email protected]>; +Cc: pgsql-hackers; Michael Paquier <[email protected]>; Andres Freund <[email protected]>
Hi,
On Tue, Mar 18, 2025 at 07:14:12PM +0800, Xuneng Zhou wrote:
> Hi,
>
> I performed some tests using elog
Thanks for the testing!
> (no so sure whether this is the proper way
> to do it) to monitor the new method.
Well that simple enough and that works well if the goal is just to "count" ;-)
> Here are the findings:
>
> • With PGSTAT_MIN_INTERVAL set to 1000ms, the number of flush reports was
> reduced to approximately 40–50 during the installcheck test suite.
>
> • With PGSTAT_IDLE_INTERVAL set to 10000ms, the reports dropped to fewer
> than 5.
>
> • In contrast, the previous approach—flushing after every
> WalSndKeepaliveIfNecessary()—resulted in roughly 50,000 flushes.
>
> This reduction is significant, so the overhead from the flush reports is no
> longer a concern.
Yeah I did observe and do think the same.
> However, we still need to determine whether this
> frequency is sufficient to capture the system’s state during periods of
> high WAL activity.
I think that reporting at PGSTAT_MIN_INTERVAL is fine and more than enough. I
mean, I 'm not sure that there is a real use case to query the statistics related
view at more than a second interval anyway. Or are you concerned that we may not
enter the "When the WAL sender is caught up or has pending data to send" frequently
enough?
> Based on my tests, using PGSTAT_MIN_INTERVAL seems to
> provide a better balance than PGSTAT_IDLE_INTERVAL.
Same here.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
@ 2025-03-19 01:53 ` Xuneng Zhou <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Xuneng Zhou @ 2025-03-19 01:53 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: pgsql-hackers; Andres Freund <[email protected]>; Michael Paquier <[email protected]>
Hi,
I am OK with PGSTAT_MIN_INTERVAL. It has been used for flushing other
statistics as well. And monitoring systems are generally configured to poll
at one-second or longer intervals.
>
> I think that reporting at PGSTAT_MIN_INTERVAL is fine and more than
> enough. I
> mean, I 'm not sure that there is a real use case to query the statistics
> related
> view at more than a second interval anyway.
I think these two conditions are good too. In a busy system, they are met
frequently, so the flush routine will be executed at least once every
second. Conversely, when WAL generation is low, there's simply less data to
record, and the flush frequency naturally decreases.
> Or are you concerned that we may not
> enter the "When the WAL sender is caught up or has pending data to send"
> frequently
> enough?
>
> > Based on my tests, using PGSTAT_MIN_INTERVAL seems to
> > provide a better balance than PGSTAT_IDLE_INTERVAL.
>
> Same here.
>
>
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
@ 2025-03-19 05:26 ` Michael Paquier <[email protected]>
2025-03-19 05:50 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Michael Paquier @ 2025-03-19 05:26 UTC (permalink / raw)
To: Xuneng Zhou <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; pgsql-hackers; Andres Freund <[email protected]>
On Wed, Mar 19, 2025 at 09:53:16AM +0800, Xuneng Zhou wrote:
> I think these two conditions are good too. In a busy system, they are met
> frequently, so the flush routine will be executed at least once every
> second. Conversely, when WAL generation is low, there's simply less data to
> record, and the flush frequency naturally decreases.
Hmm, yeah, perhaps this is acceptable. The changes in pgstat.c seem
inconsistent, though, only moving the min interval while the max and
idle times stay around.
This also make me wonder if we should work towards extending
pgstat_report_stat(), so as we save in GetCurrentTimestamp() while
making the internals still local to pgstat.c. Or perhaps not in the
scope of a backpatchable design.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
@ 2025-03-19 05:50 ` Bertrand Drouvot <[email protected]>
2025-03-19 08:00 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Bertrand Drouvot @ 2025-03-19 05:50 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Xuneng Zhou <[email protected]>; pgsql-hackers; Andres Freund <[email protected]>
Hi,
On Wed, Mar 19, 2025 at 02:26:47PM +0900, Michael Paquier wrote:
> On Wed, Mar 19, 2025 at 09:53:16AM +0800, Xuneng Zhou wrote:
> > I think these two conditions are good too. In a busy system, they are met
> > frequently, so the flush routine will be executed at least once every
> > second. Conversely, when WAL generation is low, there's simply less data to
> > record, and the flush frequency naturally decreases.
>
> Hmm, yeah, perhaps this is acceptable. The changes in pgstat.c seem
> inconsistent, though, only moving the min interval while the max and
> idle times stay around.
That's right. OTOH that sounds weird to move the others 2: that would create
wider visibility for them without real needs. That's not a big issue,
but could impact extensions or friends that would start using those should we
change their values in the future.
Another option could be to create a dedicated one in walsender.c but I'm not
sure I like it more.
> This also make me wonder if we should work towards extending
> pgstat_report_stat(), so as we save in GetCurrentTimestamp() while
> making the internals still local to pgstat.c. Or perhaps not in the
> scope of a backpatchable design.
I see. I think I'd vote for making the same changes on HEAD and the STABLE branches
as a first step. And then think about a new "design" that could be part of the
ideas suggested by Andres in [1]. Thoughts?
Regards,
[1]: https://www.postgresql.org/message-id/erpzwxoptqhuptdrtehqydzjapvroumkhh7lc6poclbhe7jk7l%40l3yfsq5q4...
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-19 05:50 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
@ 2025-03-19 08:00 ` Xuneng Zhou <[email protected]>
2025-03-23 23:41 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Xuneng Zhou @ 2025-03-19 08:00 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; [email protected]
Hi,
Moving the other two provides a more complete view of the settings. For
newcomers(like me) to the codebase, seeing all three related values in one
place helps avoid a narrow view of the settings.
But I am not sure that I understand the cons of this well.
Bertrand Drouvot <[email protected]> 于2025年3月19日周三 13:50写道：
> Hi,
>
> On Wed, Mar 19, 2025 at 02:26:47PM +0900, Michael Paquier wrote:
> > On Wed, Mar 19, 2025 at 09:53:16AM +0800, Xuneng Zhou wrote:
> > > I think these two conditions are good too. In a busy system, they are
> met
> > > frequently, so the flush routine will be executed at least once every
> > > second. Conversely, when WAL generation is low, there's simply less
> data to
> > > record, and the flush frequency naturally decreases.
> >
> > Hmm, yeah, perhaps this is acceptable. The changes in pgstat.c seem
> > inconsistent, though, only moving the min interval while the max and
> > idle times stay around.
>
> That's right. OTOH that sounds weird to move the others 2: that would
> create
> wider visibility for them without real needs. That's not a big issue,
> but could impact extensions or friends that would start using those should
> we
> change their values in the future.
>
The current name of the min interval appears consistent within the context
of the surrounding code in this patch.
Another option could be to create a dedicated one in walsender.c but I'm not
> sure I like it more.
>
>
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-19 05:50 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 08:00 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
@ 2025-03-23 23:41 ` Michael Paquier <[email protected]>
2025-03-31 13:05 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Michael Paquier @ 2025-03-23 23:41 UTC (permalink / raw)
To: Xuneng Zhou <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; Andres Freund <[email protected]>; [email protected]
On Wed, Mar 19, 2025 at 04:00:49PM +0800, Xuneng Zhou wrote:
> Hi,
> Moving the other two provides a more complete view of the settings. For
> newcomers(like me) to the codebase, seeing all three related values in one
> place helps avoid a narrow view of the settings.
>
> But I am not sure that I understand the cons of this well.
While I don't disagree with the use of a hardcoded interval of time to
control timing the flush of the WAL sender stats, do we really need to
rely on the timing defined by pgstat.c? Wouldn't it be simpler to
assign one in walsender.c and pick up a different, perhaps higher,
value?
At the end the timestamp calculations are free because we can rely on
the existing call of GetCurrentTimestamp() for the physical WAL
senders to get an idea of the current time. For the logical WAL
senders, perhaps we'd better do the reports in WalSndWaitForWal(),
actually. There is also a call to GetCurrentTimestamp() that we can
rely on in this path.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-19 05:50 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 08:00 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-23 23:41 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
@ 2025-03-31 13:05 ` Bertrand Drouvot <[email protected]>
2025-04-03 03:55 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Bertrand Drouvot @ 2025-03-31 13:05 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Xuneng Zhou <[email protected]>; Andres Freund <[email protected]>; [email protected]
Hi,
On Mon, Mar 24, 2025 at 08:41:20AM +0900, Michael Paquier wrote:
> On Wed, Mar 19, 2025 at 04:00:49PM +0800, Xuneng Zhou wrote:
> > Hi,
> > Moving the other two provides a more complete view of the settings. For
> > newcomers(like me) to the codebase, seeing all three related values in one
> > place helps avoid a narrow view of the settings.
> >
> > But I am not sure that I understand the cons of this well.
>
> While I don't disagree with the use of a hardcoded interval of time to
> control timing the flush of the WAL sender stats, do we really need to
> rely on the timing defined by pgstat.c?
No but I thought it could make sense.
> Wouldn't it be simpler to
> assign one in walsender.c and pick up a different, perhaps higher,
> value?
I don't have a strong opinion on it so done as suggested above in the attached.
I think that the 1s value is fine because: 1. it is consistent with
PGSTAT_MIN_INTERVAL and 2. it already needs that the sender is caught up or
has pending data to send (means it could be higher than 1s already). That said,
I don't think that would hurt if you think of a higher value.
> At the end the timestamp calculations are free because we can rely on
> the existing call of GetCurrentTimestamp() for the physical WAL
> senders to get an idea of the current time.
Yup
> For the logical WAL
> senders, perhaps we'd better do the reports in WalSndWaitForWal(),
> actually. There is also a call to GetCurrentTimestamp() that we can
> rely on in this path.
I think it's better to flush the stats in a shared code path. I think it's
easier to maintain and that there is no differences between logical and
physical walsenders that would justify to flush the stats in specific code
paths.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-19 05:50 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 08:00 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-23 23:41 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-31 13:05 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
@ 2025-04-03 03:55 ` vignesh C <[email protected]>
2025-04-03 07:24 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: vignesh C @ 2025-04-03 03:55 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: Michael Paquier <[email protected]>; Xuneng Zhou <[email protected]>; Andres Freund <[email protected]>; [email protected]
On Mon, 31 Mar 2025 at 18:35, Bertrand Drouvot
<[email protected]> wrote:
>
> Hi,
>
> On Mon, Mar 24, 2025 at 08:41:20AM +0900, Michael Paquier wrote:
> > On Wed, Mar 19, 2025 at 04:00:49PM +0800, Xuneng Zhou wrote:
> > > Hi,
> > > Moving the other two provides a more complete view of the settings. For
> > > newcomers(like me) to the codebase, seeing all three related values in one
> > > place helps avoid a narrow view of the settings.
> > >
> > > But I am not sure that I understand the cons of this well.
> >
> > While I don't disagree with the use of a hardcoded interval of time to
> > control timing the flush of the WAL sender stats, do we really need to
> > rely on the timing defined by pgstat.c?
>
> No but I thought it could make sense.
>
> > Wouldn't it be simpler to
> > assign one in walsender.c and pick up a different, perhaps higher,
> > value?
>
> I don't have a strong opinion on it so done as suggested above in the attached.
>
> I think that the 1s value is fine because: 1. it is consistent with
> PGSTAT_MIN_INTERVAL and 2. it already needs that the sender is caught up or
> has pending data to send (means it could be higher than 1s already). That said,
> I don't think that would hurt if you think of a higher value.
>
> > At the end the timestamp calculations are free because we can rely on
> > the existing call of GetCurrentTimestamp() for the physical WAL
> > senders to get an idea of the current time.
>
> Yup
>
> > For the logical WAL
> > senders, perhaps we'd better do the reports in WalSndWaitForWal(),
> > actually. There is also a call to GetCurrentTimestamp() that we can
> > rely on in this path.
>
> I think it's better to flush the stats in a shared code path. I think it's
> easier to maintain and that there is no differences between logical and
> physical walsenders that would justify to flush the stats in specific code
> paths.
Couple of suggestions:
1) I felt we can include a similar verification for one of the logical
replication tests too:
+# Wait for the walsender to update its IO statistics.
+# Has to be done before the next restart and far enough from the
+# pg_stat_reset_shared('io') to minimize the risk of polling for too long.
+$node_primary->poll_query_until(
+ 'postgres',
+ qq[SELECT sum(reads) > 0
+ FROM pg_catalog.pg_stat_io
+ WHERE backend_type = 'walsender'
+ AND object = 'wal']
+ )
+ or die
+ "Timed out while waiting for the walsender to update its IO statistics";
+
2) We can comment this in a single line itself:
+ /*
+ * Report IO statistics
+ */
Regards,
Vignesh
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-19 05:50 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 08:00 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-23 23:41 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-31 13:05 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-03 03:55 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
@ 2025-04-03 07:24 ` Bertrand Drouvot <[email protected]>
2025-04-03 09:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Bertrand Drouvot @ 2025-04-03 07:24 UTC (permalink / raw)
To: vignesh C <[email protected]>; +Cc: Michael Paquier <[email protected]>; Xuneng Zhou <[email protected]>; Andres Freund <[email protected]>; [email protected]
Hi,
On Thu, Apr 03, 2025 at 09:25:02AM +0530, vignesh C wrote:
> On Mon, 31 Mar 2025 at 18:35, Bertrand Drouvot
> <[email protected]> wrote:
> >
> Couple of suggestions:
Thanks for looking at it!
> 1) I felt we can include a similar verification for one of the logical
> replication tests too:
> +# Wait for the walsender to update its IO statistics.
>
> +# Has to be done before the next restart and far enough from the
> +# pg_stat_reset_shared('io') to minimize the risk of polling for too long.
> +$node_primary->poll_query_until(
> + 'postgres',
> + qq[SELECT sum(reads) > 0
> + FROM pg_catalog.pg_stat_io
> + WHERE backend_type = 'walsender'
> + AND object = 'wal']
> + )
> + or die
> + "Timed out while waiting for the walsender to update its IO statistics";
> +
Initially ([1]) it was added in 035_standby_logical_decoding.pl. But this
test (035) is already racy enough that I felt better to move it to 001_stream_rep.pl
(see [2]) instead.
I don't think that's a big issue as the code path being changed in the patch is
shared between logical and physical walsenders. That said that would not hurt to
add a logical walsender test, but I would prefer it to be outside
035_standby_logical_decoding.pl. Do you have a suggestion for the location of
such a test?
> 2) We can comment this in a single line itself:
> + /*
> + * Report IO statistics
> + */
Right, but:
- it's already done that way in walsender.c (see "Try to flush any pending output to the client"
for example).
- the exact same comment is written that way in pgstat_bgwriter.c and
pgstat_checkpointer.c
So that I just copy/paste it.
[1]: https://www.postgresql.org/message-id/Z73IsKBceoVd4t55%40ip-10-97-1-34.eu-west-3.compute.internal
[2]: https://www.postgresql.org/message-id/Z77jgvhwOu9S0a5r%40ip-10-97-1-34.eu-west-3.compute.internal
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-19 05:50 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 08:00 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-23 23:41 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-31 13:05 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-03 03:55 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-03 07:24 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
@ 2025-04-03 09:53 ` vignesh C <[email protected]>
2025-04-04 05:01 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: vignesh C @ 2025-04-03 09:53 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: Michael Paquier <[email protected]>; Xuneng Zhou <[email protected]>; Andres Freund <[email protected]>; [email protected]
On Thu, 3 Apr 2025 at 12:54, Bertrand Drouvot
<[email protected]> wrote:
>
> Hi,
>
> On Thu, Apr 03, 2025 at 09:25:02AM +0530, vignesh C wrote:
> > On Mon, 31 Mar 2025 at 18:35, Bertrand Drouvot
> > <[email protected]> wrote:
> > >
> > Couple of suggestions:
>
> Thanks for looking at it!
>
> > 1) I felt we can include a similar verification for one of the logical
> > replication tests too:
> > +# Wait for the walsender to update its IO statistics.
> >
> > +# Has to be done before the next restart and far enough from the
> > +# pg_stat_reset_shared('io') to minimize the risk of polling for too long.
> > +$node_primary->poll_query_until(
> > + 'postgres',
> > + qq[SELECT sum(reads) > 0
> > + FROM pg_catalog.pg_stat_io
> > + WHERE backend_type = 'walsender'
> > + AND object = 'wal']
> > + )
> > + or die
> > + "Timed out while waiting for the walsender to update its IO statistics";
> > +
>
> Initially ([1]) it was added in 035_standby_logical_decoding.pl. But this
> test (035) is already racy enough that I felt better to move it to 001_stream_rep.pl
> (see [2]) instead.
>
> I don't think that's a big issue as the code path being changed in the patch is
> shared between logical and physical walsenders. That said that would not hurt to
> add a logical walsender test, but I would prefer it to be outside
> 035_standby_logical_decoding.pl. Do you have a suggestion for the location of
> such a test?
Can we add it to one of the subscription tests, such as 001_rep_changes.pl?
Regards,
Vignesh
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-19 05:50 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 08:00 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-23 23:41 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-31 13:05 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-03 03:55 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-03 07:24 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-03 09:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
@ 2025-04-04 05:01 ` Bertrand Drouvot <[email protected]>
2025-04-04 16:03 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Bertrand Drouvot @ 2025-04-04 05:01 UTC (permalink / raw)
To: vignesh C <[email protected]>; +Cc: Michael Paquier <[email protected]>; Xuneng Zhou <[email protected]>; Andres Freund <[email protected]>; [email protected]
Hi,
On Thu, Apr 03, 2025 at 03:23:31PM +0530, vignesh C wrote:
> Can we add it to one of the subscription tests, such as 001_rep_changes.pl?
Yeah that sounds like a good place for it. Done in the attached.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-19 05:50 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 08:00 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-23 23:41 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-31 13:05 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-03 03:55 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-03 07:24 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-03 09:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-04 05:01 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
@ 2025-04-04 16:03 ` vignesh C <[email protected]>
2025-04-07 06:31 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: vignesh C @ 2025-04-04 16:03 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: Michael Paquier <[email protected]>; Xuneng Zhou <[email protected]>; Andres Freund <[email protected]>; [email protected]
On Fri, 4 Apr 2025 at 10:31, Bertrand Drouvot
<[email protected]> wrote:
>
> Hi,
>
> On Thu, Apr 03, 2025 at 03:23:31PM +0530, vignesh C wrote:
> > Can we add it to one of the subscription tests, such as 001_rep_changes.pl?
>
> Yeah that sounds like a good place for it. Done in the attached.
The new test added currently passes even without the patch. It would
be ideal to have a test that fails without the patch and passes once
the patch is applied.
Regards,
Vignesh
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-19 05:50 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 08:00 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-23 23:41 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-31 13:05 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-03 03:55 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-03 07:24 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-03 09:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-04 05:01 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-04 16:03 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
@ 2025-04-07 06:31 ` Michael Paquier <[email protected]>
2025-04-07 07:13 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Michael Paquier @ 2025-04-07 06:31 UTC (permalink / raw)
To: vignesh C <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; Xuneng Zhou <[email protected]>; Andres Freund <[email protected]>; [email protected]
On Fri, Apr 04, 2025 at 09:33:46PM +0530, vignesh C wrote:
> The new test added currently passes even without the patch. It would
> be ideal to have a test that fails without the patch and passes once
> the patch is applied.
Right. The subscription test and logical WAL senders passes without
the patch, because we are able to catch some WAL activity through
pgoutput. The recovery test for physical WAL sender fails without the
patch on timeout.
We could need something more advanced here for the logical case, where
we could use pg_recvlogical started in the background with a hardcoded
endpos, or just kill the pg_recvlogical command once we have checked
the state of the stats. I am not sure if this is worth the cycles
spent on, TBH, so I would be happy with just the physical case checked
in TAP as it's simpler because streaming replication makes that easy
to work with.
One thing that I'm a bit unhappy about in the patch is the choice to
do the stats updates in WalSndLoop() for the logical WAL sender case,
because this forces an extra GetCurrentTimestamp() call for each loop,
and that's never a cheap system call in what can be a hot code path.
How about doing the calculations in WalSndWaitForWal() for the logical
part, relying on the existing GetCurrentTimestamp() done there?
That's also where the waits are handled for the logical part, so there
may be a good point in keeping this code more symmetric for now,
rather than split it.
Saying that, here is a version 7 with all that included, which is
simpler to read.
--
Michael
Attachments:
[text/x-diff] v7-0001-Flush-the-IO-statistics-of-active-walsenders.patch (5.7K, ../../[email protected]/2-v7-0001-Flush-the-IO-statistics-of-active-walsenders.patch)
download | inline diff:
From 9f6dadc679cdc0da7c005d005a06dad6e81020ad Mon Sep 17 00:00:00 2001
From: Bertrand Drouvot <[email protected]>
Date: Tue, 25 Feb 2025 10:18:05 +0000
Subject: [PATCH v7] Flush the IO statistics of active walsenders
The walsender does not flush its IO statistics until it exits.
The issue is there since pg_stat_io has been introduced in a9c70b46dbe.
This commits:
1. ensures it does not wait to exit to flush its IO statistics
2. flush its IO statistics periodically to not overload the walsender
3. adds a test for a physical walsender and a test for a logical walsender
---
src/backend/replication/walsender.c | 36 +++++++++++++++++++++++++--
src/test/recovery/t/001_stream_rep.pl | 15 +++++++++++
2 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
index 1028919aecb1..216baeda5cd2 100644
--- a/src/backend/replication/walsender.c
+++ b/src/backend/replication/walsender.c
@@ -91,10 +91,14 @@
#include "utils/guc.h"
#include "utils/memutils.h"
#include "utils/pg_lsn.h"
+#include "utils/pgstat_internal.h"
#include "utils/ps_status.h"
#include "utils/timeout.h"
#include "utils/timestamp.h"
+/* Minimum interval used by walsender for stats flushes, in ms */
+#define WALSENDER_STATS_FLUSH_INTERVAL 1000
+
/*
* Maximum data payload in a WAL data message. Must be >= XLOG_BLCKSZ.
*
@@ -1797,6 +1801,7 @@ WalSndWaitForWal(XLogRecPtr loc)
int wakeEvents;
uint32 wait_event = 0;
static XLogRecPtr RecentFlushPtr = InvalidXLogRecPtr;
+ TimestampTz last_flush = 0;
/*
* Fast path to avoid acquiring the spinlock in case we already know we
@@ -1817,6 +1822,7 @@ WalSndWaitForWal(XLogRecPtr loc)
{
bool wait_for_standby_at_stop = false;
long sleeptime;
+ TimestampTz now;
/* Clear any already-pending wakeups */
ResetLatch(MyLatch);
@@ -1927,7 +1933,8 @@ WalSndWaitForWal(XLogRecPtr loc)
* new WAL to be generated. (But if we have nothing to send, we don't
* want to wake on socket-writable.)
*/
- sleeptime = WalSndComputeSleeptime(GetCurrentTimestamp());
+ now = GetCurrentTimestamp();
+ sleeptime = WalSndComputeSleeptime(now);
wakeEvents = WL_SOCKET_READABLE;
@@ -1936,6 +1943,15 @@ WalSndWaitForWal(XLogRecPtr loc)
Assert(wait_event != 0);
+ /* Report IO statistics, if needed */
+ if (TimestampDifferenceExceeds(last_flush, now,
+ WALSENDER_STATS_FLUSH_INTERVAL))
+ {
+ pgstat_flush_io(false);
+ (void) pgstat_flush_backend(false, PGSTAT_BACKEND_FLUSH_IO);
+ last_flush = now;
+ }
+
WalSndWait(wakeEvents, sleeptime, wait_event);
}
@@ -2742,6 +2758,8 @@ WalSndCheckTimeOut(void)
static void
WalSndLoop(WalSndSendDataCallback send_data)
{
+ TimestampTz last_flush = 0;
+
/*
* Initialize the last reply timestamp. That enables timeout processing
* from hereon.
@@ -2836,6 +2854,9 @@ WalSndLoop(WalSndSendDataCallback send_data)
* WalSndWaitForWal() handle any other blocking; idle receivers need
* its additional actions. For physical replication, also block if
* caught up; its send_data does not block.
+ *
+ * The IO statistics are reported in WalSndWaitForWal() for the
+ * logical WAL senders.
*/
if ((WalSndCaughtUp && send_data != XLogSendLogical &&
!streamingDoneSending) ||
@@ -2843,6 +2864,7 @@ WalSndLoop(WalSndSendDataCallback send_data)
{
long sleeptime;
int wakeEvents;
+ TimestampTz now;
if (!streamingDoneReceiving)
wakeEvents = WL_SOCKET_READABLE;
@@ -2853,11 +2875,21 @@ WalSndLoop(WalSndSendDataCallback send_data)
* Use fresh timestamp, not last_processing, to reduce the chance
* of reaching wal_sender_timeout before sending a keepalive.
*/
- sleeptime = WalSndComputeSleeptime(GetCurrentTimestamp());
+ now = GetCurrentTimestamp();
+ sleeptime = WalSndComputeSleeptime(now);
if (pq_is_send_pending())
wakeEvents |= WL_SOCKET_WRITEABLE;
+ /* Report IO statistics, if needed */
+ if (TimestampDifferenceExceeds(last_flush, now,
+ WALSENDER_STATS_FLUSH_INTERVAL))
+ {
+ pgstat_flush_io(false);
+ (void) pgstat_flush_backend(false, PGSTAT_BACKEND_FLUSH_IO);
+ last_flush = now;
+ }
+
/* Sleep until something happens or we time out */
WalSndWait(wakeEvents, sleeptime, WAIT_EVENT_WAL_SENDER_MAIN);
}
diff --git a/src/test/recovery/t/001_stream_rep.pl b/src/test/recovery/t/001_stream_rep.pl
index ccd8417d449f..e55d8ec0ec17 100644
--- a/src/test/recovery/t/001_stream_rep.pl
+++ b/src/test/recovery/t/001_stream_rep.pl
@@ -42,6 +42,9 @@ $node_standby_2->init_from_backup($node_standby_1, $backup_name,
has_streaming => 1);
$node_standby_2->start;
+# Reset IO statistics, for the WAL sender check with pg_stat_io.
+$node_primary->safe_psql('postgres', "SELECT pg_stat_reset_shared('io')");
+
# Create some content on primary and check its presence in standby nodes
$node_primary->safe_psql('postgres',
"CREATE TABLE tab_int AS SELECT generate_series(1,1002) AS a");
@@ -333,6 +336,18 @@ $node_primary->psql(
note "switching to physical replication slot";
+# Wait for the walsender to update its IO statistics. This is done before
+# the next restart and far enough from the reset done above.
+$node_primary->poll_query_until(
+ 'postgres',
+ qq[SELECT sum(reads) > 0
+ FROM pg_catalog.pg_stat_io
+ WHERE backend_type = 'walsender'
+ AND object = 'wal']
+ )
+ or die
+ "Timed out while waiting for the walsender to update its IO statistics";
+
# Switch to using a physical replication slot. We can do this without a new
# backup since physical slots can go backwards if needed. Do so on both
# standbys. Since we're going to be testing things that affect the slot state,
--
2.49.0
[application/pgp-signature] signature.asc (833B, ../../[email protected]/3-signature.asc)
download
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-19 05:50 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 08:00 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-23 23:41 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-31 13:05 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-03 03:55 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-03 07:24 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-03 09:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-04 05:01 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-04 16:03 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-07 06:31 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
@ 2025-04-07 07:13 ` Bertrand Drouvot <[email protected]>
2025-04-07 23:00 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Bertrand Drouvot @ 2025-04-07 07:13 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: vignesh C <[email protected]>; Xuneng Zhou <[email protected]>; Andres Freund <[email protected]>; [email protected]
Hi,
On Mon, Apr 07, 2025 at 03:31:14PM +0900, Michael Paquier wrote:
> On Fri, Apr 04, 2025 at 09:33:46PM +0530, vignesh C wrote:
> > The new test added currently passes even without the patch. It would
> > be ideal to have a test that fails without the patch and passes once
> > the patch is applied.
>
> Right. The subscription test and logical WAL senders passes without
> the patch, because we are able to catch some WAL activity through
> pgoutput. The recovery test for physical WAL sender fails without the
> patch on timeout.
>
> We could need something more advanced here for the logical case, where
> we could use pg_recvlogical started in the background with a hardcoded
> endpos, or just kill the pg_recvlogical command once we have checked
> the state of the stats. I am not sure if this is worth the cycles
> spent on,
Another option for the logical walsender is to reset the stats once the
subscription is created like in the attached. With the attached in place the
test now fails without the patch in place (and passes with the patch).
> One thing that I'm a bit unhappy about in the patch is the choice to
> do the stats updates in WalSndLoop() for the logical WAL sender case,
> because this forces an extra GetCurrentTimestamp() call for each loop,
> and that's never a cheap system call in what can be a hot code path.
> How about doing the calculations in WalSndWaitForWal() for the logical
> part, relying on the existing GetCurrentTimestamp() done there?
> That's also where the waits are handled for the logical part, so there
> may be a good point in keeping this code more symmetric for now,
> rather than split it.
Well, while I was working on a reproducer case for the logical walsender (that
lead to the attached), I realized that the test was looping for relatively long
time before passing. Then I was changing the patch to do *exactly* what you did
propose in v7 and the logical walsender test now passes quickly enough...
So it looks like that the idea of using a "shared" code path was not that good
and that spliting physical/logical as done in v7 is a good choice.
But...
> TBH, so I would be happy with just the physical case checked
> in TAP as it's simpler because streaming replication makes that easy
> to work with.
As we now have 2 code paths I think we "really" need 2 tests. The attached
(to apply on top of v7) seems to do the job.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
commit e3d9337aa01539ce77553d95db47aa919d1f501c
Author: Bertrand Drouvot <[email protected]>
Date: Mon Apr 7 06:56:08 2025 +0000
logical walsender test
diff --git a/src/test/subscription/t/001_rep_changes.pl b/src/test/subscription/t/001_rep_changes.pl
index 8726fe04ad2..2253ee48312 100644
--- a/src/test/subscription/t/001_rep_changes.pl
+++ b/src/test/subscription/t/001_rep_changes.pl
@@ -113,6 +113,9 @@ $node_subscriber->safe_psql('postgres',
# Wait for initial table sync to finish
$node_subscriber->wait_for_subscription_sync($node_publisher, 'tap_sub');
+# To check that an active walsender updates its IO statistics below.
+$node_publisher->safe_psql('postgres', "SELECT pg_stat_reset_shared('io')");
+
my $result =
$node_subscriber->safe_psql('postgres', "SELECT count(*) FROM tab_notrep");
is($result, qq(0), 'check non-replicated table is empty on subscriber');
@@ -184,6 +187,19 @@ $result =
$node_subscriber->safe_psql('postgres', "SELECT count(*) FROM tab_no_col");
is($result, qq(2), 'check replicated changes for table having no columns');
+# Wait for the walsender to update its IO statistics.
+# Has to be done before the next restart and far enough from the
+# pg_stat_reset_shared('io') to minimize the risk of polling for too long.
+$node_publisher->poll_query_until(
+ 'postgres',
+ qq[SELECT sum(reads) > 0
+ FROM pg_catalog.pg_stat_io
+ WHERE backend_type = 'walsender'
+ AND object = 'wal']
+ )
+ or die
+ "Timed out while waiting for the walsender to update its IO statistics";
+
# insert some duplicate rows
$node_publisher->safe_psql('postgres',
"INSERT INTO tab_full SELECT generate_series(1,10)");
Attachments:
[text/plain] add_logical_walsender_test.txt (1.6K, ../../Z%[email protected]/2-add_logical_walsender_test.txt)
download | inline diff:
commit e3d9337aa01539ce77553d95db47aa919d1f501c
Author: Bertrand Drouvot <[email protected]>
Date: Mon Apr 7 06:56:08 2025 +0000
logical walsender test
diff --git a/src/test/subscription/t/001_rep_changes.pl b/src/test/subscription/t/001_rep_changes.pl
index 8726fe04ad2..2253ee48312 100644
--- a/src/test/subscription/t/001_rep_changes.pl
+++ b/src/test/subscription/t/001_rep_changes.pl
@@ -113,6 +113,9 @@ $node_subscriber->safe_psql('postgres',
# Wait for initial table sync to finish
$node_subscriber->wait_for_subscription_sync($node_publisher, 'tap_sub');
+# To check that an active walsender updates its IO statistics below.
+$node_publisher->safe_psql('postgres', "SELECT pg_stat_reset_shared('io')");
+
my $result =
$node_subscriber->safe_psql('postgres', "SELECT count(*) FROM tab_notrep");
is($result, qq(0), 'check non-replicated table is empty on subscriber');
@@ -184,6 +187,19 @@ $result =
$node_subscriber->safe_psql('postgres', "SELECT count(*) FROM tab_no_col");
is($result, qq(2), 'check replicated changes for table having no columns');
+# Wait for the walsender to update its IO statistics.
+# Has to be done before the next restart and far enough from the
+# pg_stat_reset_shared('io') to minimize the risk of polling for too long.
+$node_publisher->poll_query_until(
+ 'postgres',
+ qq[SELECT sum(reads) > 0
+ FROM pg_catalog.pg_stat_io
+ WHERE backend_type = 'walsender'
+ AND object = 'wal']
+ )
+ or die
+ "Timed out while waiting for the walsender to update its IO statistics";
+
# insert some duplicate rows
$node_publisher->safe_psql('postgres',
"INSERT INTO tab_full SELECT generate_series(1,10)");
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-19 05:50 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 08:00 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-23 23:41 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-31 13:05 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-03 03:55 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-03 07:24 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-03 09:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-04 05:01 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-04 16:03 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-07 06:31 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-04-07 07:13 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
@ 2025-04-07 23:00 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 37+ messages in thread
From: Michael Paquier @ 2025-04-07 23:00 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: vignesh C <[email protected]>; Xuneng Zhou <[email protected]>; Andres Freund <[email protected]>; [email protected]
On Mon, Apr 07, 2025 at 07:13:20AM +0000, Bertrand Drouvot wrote:
> As we now have 2 code paths I think we "really" need 2 tests. The attached
> (to apply on top of v7) seems to do the job.
Confirmed. I am sold on this extra location on HEAD, and it does not
impact the run time of the test as there is enough activity happening
between the resets and the poll check. So, done down to v16.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 37+ messages in thread
* Fwd: [BUG]: the walsender does not update its IO statistics until it exits
@ 2025-03-13 11:33 ` Xuneng Zhou <[email protected]>
2025-03-13 13:18 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
3 siblings, 1 reply; 37+ messages in thread
From: Xuneng Zhou @ 2025-03-13 11:33 UTC (permalink / raw)
To: [email protected]; +Cc: Michael Paquier <[email protected]>; Andres Freund <[email protected]>
Forgot to cc...
---------- Forwarded message ---------
发件人： Xuneng Zhou <[email protected]>
Date: 2025年3月13日周四 19:15
Subject: Re: [BUG]: the walsender does not update its IO statistics until
it exits
To: Bertrand Drouvot <[email protected]>
Hi,
Thanks for working on this! I'm glad to see that the patch (
https://www.postgresql.org/message-id/flat/Z3zqc4o09dM/[email protected])
has been committed.
Regarding patch 0001, the optimization in pgstat_backend_have_pending_cb
looks good:
bool
pgstat_backend_have_pending_cb(void)
{
- return (!pg_memory_is_all_zeros(&PendingBackendStats,
- sizeof(struct PgStat_BackendPending)));
+ return backend_has_iostats;
}
Additionally, the function pgstat_flush_backend includes the check:
+ if (!pgstat_backend_have_pending_cb())
return false;
However, I think we might need to revise the comment (and possibly the
function name) for clarity:
/*
* Check if there are any backend stats waiting to be flushed.
*/
Originally, this function was intended to check multiple types of backend
statistics, which made sense when PendingBackendStats was the centralized
structure for various pending backend stats. However, since
PgStat_PendingWalStats was removed from PendingBackendStats earlier, and
now this patch introduces the backend_has_iostats variable, the scope of
this function appears even narrower. This narrowed functionality no longer
aligns closely with the original function name and its associated comment.
Bertrand Drouvot <[email protected]> 于2025年3月3日周一 19:54写道：
> Hi,
>
> On Mon, Mar 03, 2025 at 10:51:19AM +0900, Michael Paquier wrote:
> > On Fri, Feb 28, 2025 at 10:39:31AM +0000, Bertrand Drouvot wrote:
> > > That sounds a good idea to measure the impact of those extra calls and
> see
> > > if we'd need to mitigate the impacts. I'll collect some data.
>
> So I did some tests using only one walsender (given the fact that the extra
> lock you mentioned above is "only" for this particular backend).
>
> === Test with pg_receivewal
>
> I was using one pg_receivewal process and did some tests that way:
>
> pgbench -n -c8 -j8 -T60 -f <(echo "SELECT pg_logical_emit_message(true,
> 'test', repeat('0', 1));";)
>
> I did not measure any noticeable extra lag (I did measure the time it took
> for pg_size_pretty(sent_lsn - write_lsn) from pg_stat_replication to be
> back
> to zero).
>
> During the pgbench run a "perf record --call-graph fp -p <walsender_pid>"
> would
> report (perf report -n):
>
> 1. pgstat_flush_backend() appears at about 3%
> 2. pg_memory_is_all_zeros() at about 2.8%
> 3. pgstat_flush_io() at about 0.4%
>
> So it does not look like what we're adding here can be seen as a primary
> bottleneck.
>
> That said it looks like that there is room for improvment in
> pgstat_flush_backend()
> and that relying on a "have_iostats" like variable would be better than
> those
> pg_memory_is_all_zeros() calls.
>
> That's done in 0001 attached, by doing so, pgstat_flush_backend() now
> appears at
> about 0.2%.
>
> === Test with pg_recvlogical
>
> Now it does not look like pg_receivewal had a lot of IO stats to report
> (looking at
> pg_stat_get_backend_io() output for the walsender).
>
> Doing the same test with "pg_recvlogical -d postgres -S logical_slot -f
> /dev/null --start"
> reports much more IO stats.
>
> What I observe without the "have_iostats" optimization is:
>
> 1. I did not measure any noticeable extra lag
> 2. pgstat_flush_io() at about 5.5% (pgstat_io_flush_cb() at about 5.3%)
> 3 pgstat_flush_backend() at about 4.8%
>
> and with the "have_iostats" optimization I now see pgstat_flush_backend()
> at
> about 2.51%.
>
> So it does not look like what we're adding here can be seen as a primary
> bottleneck
> but that is probably worth implementing the "have_iostats" optimization
> attached.
>
> Also, while I did not measure any noticeable extra lag, given the fact
> that
> pgstat_flush_io() shows at about 5.5% and pgstat_flush_backend() at about
> 2.5%,
> that could still make sense to reduce the frequency of the flush calls,
> thoughts?
>
> Regards,
>
> --
> Bertrand Drouvot
> PostgreSQL Contributors Team
> RDS Open Source Databases
> Amazon Web Services: https://aws.amazon.com
>
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-13 11:33 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
@ 2025-03-13 13:18 ` Bertrand Drouvot <[email protected]>
2025-03-18 08:11 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Bertrand Drouvot @ 2025-03-13 13:18 UTC (permalink / raw)
To: Xuneng Zhou <[email protected]>; +Cc: [email protected]; Michael Paquier <[email protected]>; Andres Freund <[email protected]>
Hi,
On Thu, Mar 13, 2025 at 07:33:24PM +0800, Xuneng Zhou wrote:
> Regarding patch 0001, the optimization in pgstat_backend_have_pending_cb
> looks good:
Thanks for looking at it!
> bool
> pgstat_backend_have_pending_cb(void)
> {
> - return (!pg_memory_is_all_zeros(&PendingBackendStats,
> - sizeof(struct PgStat_BackendPending)));
> + return backend_has_iostats;
> }
>
> Additionally, the function pgstat_flush_backend includes the check:
>
> + if (!pgstat_backend_have_pending_cb())
> return false;
>
> However, I think we might need to revise the comment (and possibly the
> function name) for clarity:
>
> /*
> * Check if there are any backend stats waiting to be flushed.
> */
The comment is not exactly this one on the current HEAD, it looks like that you're
looking at a previous version of the core code.
> Originally, this function was intended to check multiple types of backend
> statistics, which made sense when PendingBackendStats was the centralized
> structure for various pending backend stats. However, since
> PgStat_PendingWalStats was removed from PendingBackendStats earlier, and
> now this patch introduces the backend_has_iostats variable, the scope of
> this function appears even narrower. This narrowed functionality no longer
> aligns closely with the original function name and its associated comment.
I don't think so, as since 76def4cdd7c, a pgstat_backend_wal_have_pending() check
has been added to pgstat_backend_have_pending_cb(). You're probably looking at
a version prior to 76def4cdd7c.
This particular sub-patch needs a rebase though, done in the attached. 0001
remains unchanged as compared to the v4 one just shared up-thread. If 0001 goes
in, merging 0002 would be less beneficial (as compared to v3).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-13 11:33 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:18 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
@ 2025-03-18 08:11 ` Michael Paquier <[email protected]>
2025-03-18 09:51 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Michael Paquier @ 2025-03-18 08:11 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: Xuneng Zhou <[email protected]>; [email protected]; Andres Freund <[email protected]>
On Thu, Mar 13, 2025 at 01:18:45PM +0000, Bertrand Drouvot wrote:
> This particular sub-patch needs a rebase though, done in the attached. 0001
> remains unchanged as compared to the v4 one just shared up-thread. If 0001 goes
> in, merging 0002 would be less beneficial (as compared to v3).
PgStat_PendingIO is already quite large, could get larger, and the
backend stats would be a natural victim of that. What you are
proposing in v4-0002 is beneficial in any case outside of the specific
problem of this thread with WAL senders. It is new code on HEAD and
pgstat_flush_backend_entry_io() being the only entry point where IO
data is appended makes it easy to reason about. Just to say that I am
planning to apply this part on HEAD.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-13 11:33 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:18 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 08:11 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
@ 2025-03-18 09:51 ` Bertrand Drouvot <[email protected]>
2025-03-18 23:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Bertrand Drouvot @ 2025-03-18 09:51 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Xuneng Zhou <[email protected]>; [email protected]; Andres Freund <[email protected]>
Hi,
On Tue, Mar 18, 2025 at 05:11:02PM +0900, Michael Paquier wrote:
> On Thu, Mar 13, 2025 at 01:18:45PM +0000, Bertrand Drouvot wrote:
> > This particular sub-patch needs a rebase though, done in the attached. 0001
> > remains unchanged as compared to the v4 one just shared up-thread. If 0001 goes
> > in, merging 0002 would be less beneficial (as compared to v3).
>
> PgStat_PendingIO is already quite large, could get larger, and the
> backend stats would be a natural victim of that. What you are
> proposing in v4-0002 is beneficial in any case outside of the specific
> problem of this thread with WAL senders.
Yeah, I also think it makes sense independently of what has been discussed
in this thread.
> Just to say that I am planning to apply this part on HEAD.
Thanks!
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-13 11:33 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:18 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 08:11 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-18 09:51 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
@ 2025-03-18 23:19 ` Michael Paquier <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 37+ messages in thread
From: Michael Paquier @ 2025-03-18 23:19 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: Xuneng Zhou <[email protected]>; [email protected]; Andres Freund <[email protected]>
On Tue, Mar 18, 2025 at 09:51:14AM +0000, Bertrand Drouvot wrote:
> Thanks!
Done that part for now. It will be possible to look at the bug fix
after the release freeze as it impacts stable branches as well.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits
2025-03-13 11:33 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:18 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 08:11 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-18 09:51 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 23:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
@ 2025-03-19 05:26 ` Bertrand Drouvot <[email protected]>
0 siblings, 0 replies; 37+ messages in thread
From: Bertrand Drouvot @ 2025-03-19 05:26 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Xuneng Zhou <[email protected]>; [email protected]; Andres Freund <[email protected]>
Hi,
On Wed, Mar 19, 2025 at 08:19:42AM +0900, Michael Paquier wrote:
>
> Done that part for now.
Thanks!
> It will be possible to look at the bug fix
> after the release freeze as it impacts stable branches as well.
Yes, let's do that. Adding a reminder on my side.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: [BUG]: the walsender does not update its IO statistics until it exits
@ 2025-09-30 07:16 ` Bertrand Drouvot <[email protected]>
3 siblings, 0 replies; 37+ messages in thread
From: Bertrand Drouvot @ 2025-09-30 07:16 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Michael Paquier <[email protected]>; [email protected]
Hi,
On Wed, Feb 26, 2025 at 05:08:17AM -0500, Andres Freund wrote:
> Hi,
>
> On 2025-02-26 15:37:10 +0900, Michael Paquier wrote:
> > That's bad, worse for a logical WAL sender, because it means that we
> > have no idea what kind of I/O happens in this process until it exits,
> > and logical WAL senders could loop forever, since v16 where we've
> > begun tracking I/O.
>
> FWIW, I think medium term we need to work on splitting stats flushing into two
> separate kinds of flushes:
> 1) non-transactional stats, which should be flushed at a regular interval,
> unless a process is completely idle
> 2) transaction stats, which can only be flushed at transaction boundaries,
> because before the transaction boundary we don't know if e.g. newly
> inserted rows should be counted as live or dead
>
> So far we have some timer logic for 2), but we have basically no support for
> 1). Which means we have weird ad-hoc logic in various kinds of
> non-plain-connection processes. And that will often have holes, as Bertrand
> noticed here.
>
> I think it's also bad that we don't have a solution for 1), even just for
> normal connections. If a backend causes a lot of IO we might want to know
> about that long before the longrunning transaction commits.
>
> I suspect the right design here would be to have a generalized form of the
> timeout mechanism we have for 2).
>
> For that we'd need to make sure that pgstat_report_stat() can be safely called
> inside a transaction.
I can see an issue with GetCurrentTransactionStopTimestamp(), any other issue
/concern you have in mind?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 37+ messages in thread
end of thread, other threads:[~2025-10-01 14:21 UTC | newest]
Thread overview: 37+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-06-14 21:05 [PATCH v1 2/8] code: s/master/primary/ Andres Freund <[email protected]>
2025-02-27 03:09 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-02-27 10:06 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Andres Freund <[email protected]>
2025-09-30 07:14 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-09-30 07:37 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-09-30 10:05 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-09-30 22:43 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-10-01 14:21 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-10 00:23 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-10 14:52 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-11 06:10 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 09:31 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-13 11:35 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 11:14 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-18 14:45 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 01:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-19 05:50 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-19 08:00 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-23 23:41 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-31 13:05 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-03 03:55 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-03 07:24 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-03 09:53 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-04 05:01 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-04 16:03 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits vignesh C <[email protected]>
2025-04-07 06:31 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-04-07 07:13 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-04-07 23:00 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-13 11:33 ` Fwd: [BUG]: the walsender does not update its IO statistics until it exits Xuneng Zhou <[email protected]>
2025-03-13 13:18 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 08:11 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-18 09:51 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-03-18 23:19 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Michael Paquier <[email protected]>
2025-03-19 05:26 ` Re: Fwd: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
2025-09-30 07:16 ` Re: [BUG]: the walsender does not update its IO statistics until it exits Bertrand Drouvot <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox