RecoveryWalAll and RecoveryWalStream wait events

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: RecoveryWalAll and RecoveryWalStream wait events
Date: 2020-02-18 03:25:51
Message-ID: 124997ee-096a-5d09-d8da-2c7a57d0816e@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

RecoveryWalAll and RecoveryWalStream wait events are documented as follows.

RecoveryWalAll
Waiting for WAL from any kind of source (local, archive or stream) at recovery.

RecoveryWalStream
Waiting for WAL from a stream at recovery.

But as far as I read the code, RecoveryWalAll is reported only when waiting
for WAL from a stream. So the current description looks incorrect. What's
described now for RecoveryWalStream seems rather fit to RecoveryWalAll.
I'd like to change the description of RecoveryWalAll to "Waiting for WAL
from a stream at recovery".

Regarding RecoveryWalStream, as far as I read the code, while this event is
being reported, the startup process is waiting for next trial to retrieve
WAL data when WAL data is not available from any sources, based on
wal_retrieve_retry_interval. So this current description looks also
incorrect. I'd like to change it to "Waiting when WAL data is not available
from any kind of sources (local, archive or stream) before trying again
to retrieve WAL data".

Thought?

Also the current names of these wait events sound confusing. I think
that RecoveryWalAll should be changed to RecoveryWalStream.
RecoveryWalStream should be RecoveryRetrieveRetryInterval or
something.

Another problem is that the current wait event types of them also look
strange. Currently the type of them is Activity, but IMO it's better to
use IPC for RecoveryWalAll because it's waiting for walreceiver to
receive new WAL. Also it's better to use Timeout for RecoveryWalStream
because it's waiting depending on wal_retrieve_retry_interval.

The changes of wait event types and names would break the compatibility
of wait events in pg_stat_activity. So this change should not be applied
to the back branches, but it's ok to apply in the master. Right?

Regards,

--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-02-18 03:30:32 Re: ssl passphrase callback
Previous Message Michael Paquier 2020-02-18 03:25:22 Re: Duplicate words in comments