Re: Tracking wait event for latches

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Tracking wait event for latches
Date: 2016-09-26 04:46:48
Message-ID: CAEepm=0X6WiRR5pr9if=_n9=s8XPgG688Wee0tGnR7jWt=h8RA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 24, 2016 at 1:44 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> After digesting all the comments given, I have produced the patch
> attached that uses the following categories:
> +const char *const WaitEventNames[] = {
> + /* activity */
> + "ArchiverMain",
> + "AutoVacuumMain",
> + "BgWriterHibernate",
> + "BgWriterMain",
> + "CheckpointerMain",
> + "PgStatMain",
> + "RecoveryWalAll",
> + "RecoveryWalStream",
> + "SysLoggerMain",
> + "WalReceiverMain",
> + "WalSenderMain",
> + "WalWriterMain",
> + /* client */
> + "SecureRead",
> + "SecureWrite",
> + "SSLOpenServer",
> + "WalReceiverWaitStart",
> + "WalSenderWaitForWAL",
> + "WalSenderWriteData",
> + /* Extension */
> + "Extension",
> + /* IPC */
> + "BgWorkerShutdown",
> + "BgWorkerStartup",
> + "ExecuteGather",
> + "MessageQueueInternal",
> + "MessageQueuePutMessage",
> + "MessageQueueReceive",
> + "MessageQueueSend",
> + "ParallelFinish",
> + "ProcSignal",
> + "ProcSleep",
> + "SyncRep",
> + /* timeout */
> + "BaseBackupThrottle",
> + "PgSleep",
> + "RecoveryApplyDelay",
> +};
> I have moved WalSenderMain as it tracks a main loop, so it was strange
> to not have it in Activity. I also kept SecureRead and SecureWrite
> because this is referring to the functions of the same name. For the
> rest, I got convinced by what has been discussed and it makes things
> clearer. My head is not spinning anymore when I try to keep in sync
> the list of names and its associated enum, which is good. I have as
> well rewritten the docs to follow that.

-extern int WaitEventSetWait(WaitEventSet *set, long timeout,
WaitEvent *occurred_events, int nevents);
-extern int WaitLatch(volatile Latch *latch, int wakeEvents, long timeout);
+extern int WaitEventSetWait(WaitEventSet *set, long timeout,
+ WaitEvent *occurred_events, int nevents,
+ uint8 classId, uint16 eventId);
+extern int WaitLatch(volatile Latch *latch, int wakeEvents, long timeout,
+ uint8 classId, uint16 eventId);
extern int WaitLatchOrSocket(volatile Latch *latch, int wakeEvents,
- pgsocket sock, long timeout);
+ pgsocket sock, long timeout, uint8 classId,
+ uint16 eventId);

+ WaitLatch(MyLatch, WL_LATCH_SET, 0, WAIT_IPC, WE_MQ_RECEIVE);

If the class really is strictly implied by the WaitEventIdentifier,
then do we really need to supply it everywhere when calling the
various wait functions? That's going to be quite a few functions:
WaitLatch, WaitLatchOrSocket, WaitEventSetWait for now, and if some
more patches out there have legs then also ConditionVariableWait,
BarrierWait, and possibly further kinds of wait points. And then all
their call sites will have have to supply the wait class ID, even
though it is implied by the other ID. Perhaps that array that
currently holds the names should instead hold { classId, displayName }
so we could just look it up?

--
Thomas Munro
http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-09-26 06:02:30 Re: Password identifiers, protocol aging and SCRAM protocol
Previous Message Rafia Sabih 2016-09-26 04:29:09 "Re: Question about grant create on database and pg_dump/pg_dumpall