From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Wait event that should be reported while waiting for WAL archiving to finish
Date: Wed, 26 Feb 2020 21:19:02 +0900
Message-ID: <164cddb8-d331-753c-6a97-b181206d72d6@oss.nttdata.com> (raw)
In-Reply-To: <20200218033949.GD4176@paquier.xyz>
References: <f0651f8c-9c96-9f29-0ff9-80414a15308a@oss.nttdata.com>
<20200213032804.GB1520@paquier.xyz>
<949931aa-4ed4-d867-a7b5-de9c02b2292b@oss.nttdata.com>
<20200213073035.GI1520@paquier.xyz>
<eb1287bd-64ee-07a5-057e-710d93e7f39e@oss.nttdata.com>
<CA+Tgmoa3BVNJ+LVrytUrsK+MtxEogc_jurDgJ=rkMAEt06Hk6Q@mail.gmail.com>
<61477660-dded-2550-b101-c76a2f864806@oss.nttdata.com>
<20200217094857.GB115140@paquier.xyz>
<d9d85efa-f62e-400e-2edf-9e1b8c0df651@oss.nttdata.com>
<20200218033949.GD4176@paquier.xyz>
On 2020/02/18 12:39, Michael Paquier wrote:
> On Mon, Feb 17, 2020 at 10:21:23PM +0900, Fujii Masao wrote:
>> On 2020/02/17 18:48, Michael Paquier wrote:
>>> Actually, I have some questions:
>>> 1) Should a new wait event be added in recoveryPausesHere()? That
>>> would be IMO useful.
>>
>> Yes, it's useful, I think. But it's better to implement that
>> as a separate patch.
>
> No problem for me.
On second thought, it's OK to add that event into the patch.
Attached is the updated version of the patch. This patch adds
two wait events for WAL archiving and recovery pause.
>>> 2) Perhaps those two points should be replaced with WaitLatch(), where
>>> we would use the new wait events introduced?
>>
>> For what? Maybe it should, but I'm not sure it's worth the trouble.
>
> I don't have more to offer than signal handling consistency for both
> without relying on pg_usleep()'s behavior depending on the platform,
> and power consumption. For the recovery pause, the second argument
> may not be worth carrying, but we never had this argument for the
> archiving wait, did we?
I have no idea about this. But I wonder how much that change
is helpful to reduce the power consumption because waiting
for WAL archive during the backup basically not so frequently
happens.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
Attachments:wait_event_wal_archive_v4.patch (text/plain, 3.5K) downloaddiff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgmlindex 87586a7b06..6c0c93ffdc 100644--- a/doc/src/sgml/monitoring.sgml+++ b/doc/src/sgml/monitoring.sgml@@ -1335,7 +1335,11 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry>Waiting in an extension.</entry>
</row>
<row>
- <entry morerows="36"><literal>IPC</literal></entry>+ <entry morerows="38"><literal>IPC</literal></entry>+ <entry><literal>BackupWaitWalArchive</literal></entry>+ <entry>Waiting for WAL files required for the backup to be successfully archived.</entry>+ </row>+ <row>
<entry><literal>BgWorkerShutdown</literal></entry>
<entry>Waiting for background worker to shut down.</entry>
</row>
@@ -1467,6 +1471,10 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry><literal>Promote</literal></entry>
<entry>Waiting for standby promotion.</entry>
</row>
+ <row>+ <entry><literal>RecoveryPause</literal></entry>+ <entry>Waiting for recovery to be resumed.</entry>+ </row>
<row>
<entry><literal>ReplicationOriginDrop</literal></entry>
<entry>Waiting for a replication origin to become inactive to be dropped.</entry>
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.cindex d19408b3be..5569606183 100644--- a/src/backend/access/transam/xlog.c+++ b/src/backend/access/transam/xlog.c@@ -5945,7 +5945,9 @@ recoveryPausesHere(void)
while (RecoveryIsPaused())
{
+ pgstat_report_wait_start(WAIT_EVENT_RECOVERY_PAUSE);
pg_usleep(1000000L); /* 1000 ms */
+ pgstat_report_wait_end();
HandleStartupProcInterrupts();
}
}
@@ -11129,7 +11131,9 @@ do_pg_stop_backup(char *labelfile, bool waitforarchive, TimeLineID *stoptli_p)
reported_waiting = true;
}
+ pgstat_report_wait_start(WAIT_EVENT_BACKUP_WAIT_WAL_ARCHIVE);
pg_usleep(1000000L);
+ pgstat_report_wait_end();
if (++waits >= seconds_before_warning)
{
diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.cindex 462b4d7e06..2400bf31ee 100644--- a/src/backend/postmaster/pgstat.c+++ b/src/backend/postmaster/pgstat.c@@ -3740,6 +3740,9 @@ pgstat_get_wait_ipc(WaitEventIPC w)
switch (w)
{
+ case WAIT_EVENT_BACKUP_WAIT_WAL_ARCHIVE:+ event_name = "BackupWaitWalArchive";+ break;
case WAIT_EVENT_BGWORKER_SHUTDOWN:
event_name = "BgWorkerShutdown";
break;
@@ -3839,6 +3842,9 @@ pgstat_get_wait_ipc(WaitEventIPC w)
case WAIT_EVENT_PROMOTE:
event_name = "Promote";
break;
+ case WAIT_EVENT_RECOVERY_PAUSE:+ event_name = "RecoveryPause";+ break;
case WAIT_EVENT_REPLICATION_ORIGIN_DROP:
event_name = "ReplicationOriginDrop";
break;
diff --git a/src/include/pgstat.h b/src/include/pgstat.hindex 3a65a51696..6d8332163c 100644--- a/src/include/pgstat.h+++ b/src/include/pgstat.h@@ -817,7 +817,8 @@ typedef enum
*/
typedef enum
{
- WAIT_EVENT_BGWORKER_SHUTDOWN = PG_WAIT_IPC,+ WAIT_EVENT_BACKUP_WAIT_WAL_ARCHIVE = PG_WAIT_IPC,+ WAIT_EVENT_BGWORKER_SHUTDOWN,
WAIT_EVENT_BGWORKER_STARTUP,
WAIT_EVENT_BTREE_PAGE,
WAIT_EVENT_CLOG_GROUP_UPDATE,
@@ -850,6 +851,7 @@ typedef enum
WAIT_EVENT_PARALLEL_FINISH,
WAIT_EVENT_PROCARRAY_GROUP_UPDATE,
WAIT_EVENT_PROMOTE,
+ WAIT_EVENT_RECOVERY_PAUSE,
WAIT_EVENT_REPLICATION_ORIGIN_DROP,
WAIT_EVENT_REPLICATION_SLOT_DROP,
WAIT_EVENT_SAFE_SNAPSHOT,
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: masao.fujii@oss.nttdata.com, michael@paquier.xyz, robertmhaas@gmail.com
Subject: Re: Wait event that should be reported while waiting for WAL archiving to finish
In-Reply-To: <164cddb8-d331-753c-6a97-b181206d72d6@oss.nttdata.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox