Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tmvCS-000EBW-55 for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Feb 2025 13:42:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tmvCQ-002Acx-Ez for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Feb 2025 13:42:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tmvCQ-002Acp-15 for pgsql-hackers@lists.postgresql.org; Tue, 25 Feb 2025 13:42:14 +0000 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tmvCN-0000Wl-0O for pgsql-hackers@lists.postgresql.org; Tue, 25 Feb 2025 13:42:13 +0000 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-438a39e659cso37030625e9.2 for ; Tue, 25 Feb 2025 05:42:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740490931; x=1741095731; darn=lists.postgresql.org; h=content-disposition:mime-version:message-id:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=XqqCpS4QCugS2zzfdBhVo7lJYcbeZmKS33PBKTBOQi0=; b=h4NL3M7oQnZHzqINzNUQpaJqp0tFmw7vJ44c1gVBGDvTzjedI7k1m6FBGVIzDVaW8n LjCSmyMTjStAj2yHuE0hDiYzitjPoYmxNsPhCD7GJS/CznlsBiCSbhZEHrbGw3yLzmuh i1CLv+skj+/enIEltJKZHT7+wTOk/4Z59mne0q58vchtNdNfN9Y/wM6GvLn+ZA9KET47 A+m25fACk8PXnpcJGiC7ZbayHrs4dv3I80neGw/1wlaDF6lGyqe78rVkYHkQIPfa0vSt aUEQkHX1x/A0cazgMBxv1/C6Dh9OJn0yU5SKDBgfmXnBGsJIONypqulXAuRcharCHfbO ykyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740490931; x=1741095731; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XqqCpS4QCugS2zzfdBhVo7lJYcbeZmKS33PBKTBOQi0=; b=Py3Rf9PZsofboMU+O8YwAopxkFa4gZAl2yMJjeVDarJxtagZesi8ucGvsAVbNtwMoN EmvFGpK425KlAwPVpnhyrF3ExvO/rV3Ueh11z/q5PEZtX6T/fiNG1AGKgs4r8hV2P0WS m6sOnl8gQgJ7+fyA6EYo+O2ZJOjljEArrsOi//PxotrsL5i9e+HEPsAl54VtDbmLfsQV oOYow5/zCTL4BEup6XTv3pShc33m8vb43bnGXOmTIuBK3N2rWhoIE5pzii0F/rGGE1Rv 7lUXMcWdPEkEpQVjKjpy1yxZ2a9VK5uHy6omiCud7iml6XhyGFitAh5Gh2BNNuUQL0JI TfkQ== X-Gm-Message-State: AOJu0YwG+CeezRV96veOpm9GLdWSDWT1NsI75R2/JqIM7FAQ9qG22JO/ a/bNdSkALcSvXzmJ/wQ2UjdoFYicXShWPjhd3SkXKlJq+f3x1ZbXLfODow== X-Gm-Gg: ASbGnctaRCLQLGtifR5M2u3792Yg/M6sdoEZJ34D8MHt1RZ3xTE0w2emgoYl7l4kDGI rakIeAShrMJELjRcExuOsixewRHPPgZOl3zP0VWbC+v+OS/L/O3gFnXt2hWTAMNeUEZCHeLyAtH AkBJ3/lF01GyLCYJiX5qQ/lDPdL5hUIwRnHz4Tq4ZoH2gghCU0wuLkjHzcgyiRQvHYQp8vd4BMS yLHQlzcf0ZU6HGIkyJ4Ar91TqCW7xOdxcJdWtgWgUkjpeLO8UYrU/JksJe2VgRe957CRY9XiW72 ALg/d96EXY1Cvzle974soMECo3LIZTpRs3x7cDtK8p5QY+0iBYx6K6hrv8zwhpAr2GXeLv4pLBi qMsdcqaiFxj6h0hb3hRM8CVab8JwUPfcZPTID+wdORRI2MBC7jZpG1dDuEA== X-Google-Smtp-Source: AGHT+IHRtDXQMHrtGbe/QnWO49gmC5i0clnHrVjDmFaPWFROJOZVRL9iziBjmfrYSsCuP9Rf6nkgVA== X-Received: by 2002:a05:600c:4ece:b0:439:9274:8203 with SMTP id 5b1f17b1804b1-439aeae0543mr140154755e9.6.1740490930521; Tue, 25 Feb 2025 05:42:10 -0800 (PST) Received: from ip-10-97-1-34.eu-west-3.compute.internal (ec2-15-237-181-182.eu-west-3.compute.amazonaws.com. [15.237.181.182]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43ab1532d92sm26915075e9.3.2025.02.25.05.42.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Feb 2025 05:42:09 -0800 (PST) Date: Tue, 25 Feb 2025 13:42:08 +0000 From: Bertrand Drouvot To: pgsql-hackers@lists.postgresql.org Subject: [BUG]: the walsender does not update its IO statistics until it exits Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="dA3AL7DRjdJhpI1D" Content-Disposition: inline List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --dA3AL7DRjdJhpI1D Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi hackers, while doing some tests for [1], I observed that $SUBJECT. To observe this behavior on master: 1. create a logical replication slot postgres=# SELECT * FROM pg_create_logical_replication_slot('logical_slot', 'test_decoding', false, true); slot_name | lsn --------------+------------ logical_slot | 0/40749508 (1 row) 2. create a table and add some data postgres=# create table bdt (a int); CREATE TABLE postgres=# insert into bdt select a from generate_series(1,10000) a ; INSERT 0 10000 3. starts pg_recvlogical that way pg_recvlogical -d postgres -S logical_slot -f - --no-loop --start 4. query pg_stat_io postgres=# select backend_type,object,context,reads,read_bytes from pg_stat_io where backend_type = 'walsender'; backend_type | object | context | reads | read_bytes --------------+---------------+-----------+-------+------------ walsender | relation | bulkread | 0 | 0 walsender | relation | bulkwrite | 0 | 0 walsender | relation | init | 0 | 0 walsender | relation | normal | 6 | 49152 walsender | relation | vacuum | 0 | 0 walsender | temp relation | normal | 0 | 0 walsender | wal | init | | walsender | wal | normal | 0 | 0 (8 rows) The non zeros stats that we see here are due to the pgstat_report_stat() call in PostgresMain() but not to the walsender decoding activity per say (proof is that you can see that the wal object values are empty while it certainly had to read some WAL). 5. Once ctrl-c is done for pg_recvlogical then we get: postgres=# select backend_type,object,context,reads,read_bytes from pg_stat_io where backend_type = 'walsender'; backend_type | object | context | reads | read_bytes --------------+---------------+-----------+-------+------------ walsender | relation | bulkread | 0 | 0 walsender | relation | bulkwrite | 0 | 0 walsender | relation | init | 0 | 0 walsender | relation | normal | 9 | 73728 walsender | relation | vacuum | 0 | 0 walsender | temp relation | normal | 0 | 0 walsender | wal | init | | walsender | wal | normal | 98 | 793856 (8 rows) Now we can see that the numbers increased for the relation object and that we get non zeros numbers for the wal object too (which makes fully sense). With the attached patch applied, we would get the same numbers already in step 4. (means the stats are flushed without the need to wait for the walsender to exit). Remarks: R1. The extra flush are done in WalSndLoop(): I believe this is the right place for them. R2. A test is added in 035_standby_logical_decoding.pl: while this TAP test is already racy ([2]) that looks like a good place as we don't want pg_recvlogical to stop/exit. R3. The test can also be back-patched till 16_STABLE as 035_standby_logical_decoding.pl has been introduced in 16 (and so do pg_stat_io). R4. The test fails if the extra flushs are not applied/done, which makes fully sense. [1]: https://www.postgresql.org/message-id/flat/Z3zqc4o09dM/Ezyz%40ip-10-97-1-34.eu-west-3.compute.internal [2]: https://www.postgresql.org/message-id/Z6oRgmD8m7zBo732%40ip-10-97-1-34.eu-west-3.compute.internal Looking forward to your feedback, Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com --dA3AL7DRjdJhpI1D Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v1-0001-Flush-the-IO-statistics-of-active-walsenders.patch" From b16a0ccada3c2acc80bf733e71935677b9ab6382 Mon Sep 17 00:00:00 2001 From: Bertrand Drouvot Date: Tue, 25 Feb 2025 10:18:05 +0000 Subject: [PATCH v1] 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. adds a test --- src/backend/replication/walsender.c | 7 +++++++ .../recovery/t/035_standby_logical_decoding.pl | 15 +++++++++++++++ 2 files changed, 22 insertions(+) 26.2% src/backend/replication/ 73.7% src/test/recovery/t/ diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c index 446d10c1a7d..3664d7d0c75 100644 --- a/src/backend/replication/walsender.c +++ b/src/backend/replication/walsender.c @@ -90,6 +90,7 @@ #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" @@ -2793,6 +2794,12 @@ WalSndLoop(WalSndSendDataCallback send_data) if (pq_flush_if_writable() != 0) WalSndShutdown(); + /* + * Report IO statistics + */ + pgstat_flush_io(false); + (void) pgstat_flush_backend(false, PGSTAT_BACKEND_FLUSH_IO); + /* If nothing remains to be sent right now ... */ if (WalSndCaughtUp && !pq_is_send_pending()) { diff --git a/src/test/recovery/t/035_standby_logical_decoding.pl b/src/test/recovery/t/035_standby_logical_decoding.pl index 8903177d883..ab34d290165 100644 --- a/src/test/recovery/t/035_standby_logical_decoding.pl +++ b/src/test/recovery/t/035_standby_logical_decoding.pl @@ -543,6 +543,9 @@ $node_subscriber->stop; reactive_slots_change_hfs_and_wait_for_xmins('behaves_ok_', 'vacuum_full_', 0, 1); +# To check that an active walsender updates its IO statistics below. +$node_standby->safe_psql('testdb', "SELECT pg_stat_reset_shared('io')"); + # Ensure that replication slot stats are not empty before triggering the # conflict. $node_primary->safe_psql('testdb', @@ -552,6 +555,18 @@ $node_standby->poll_query_until('testdb', qq[SELECT total_txns > 0 FROM pg_stat_replication_slots WHERE slot_name = 'vacuum_full_activeslot'] ) or die "replication slot stats of vacuum_full_activeslot not updated"; +# Ensure an active walsender updates its IO statistics. +is( $node_standby->safe_psql( + 'testdb', + qq(SELECT reads > 0 + FROM pg_catalog.pg_stat_io + WHERE backend_type = 'walsender' + AND object = 'relation' + AND context = 'normal') + ), + qq(t), + "Check that an active walsender updates its IO statistics"); + # This should trigger the conflict wait_until_vacuum_can_remove( 'full', 'CREATE TABLE conflict_test(x integer, y text); -- 2.34.1 --dA3AL7DRjdJhpI1D--