Re: Tracking wait event for latches - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Tracking wait event for latches
Date
Msg-id CAEepm=0X6WiRR5pr9if=_n9=s8XPgG688Wee0tGnR7jWt=h8RA@mail.gmail.com
Whole thread Raw
In response to Re: Tracking wait event for latches  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Tracking wait event for latches  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Sat, Sep 24, 2016 at 1:44 AM, Michael Paquier
<michael.paquier@gmail.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



pgsql-hackers by date:

Previous
From: Rafia Sabih
Date:
Subject: "Re: Question about grant create on database and pg_dump/pg_dumpall
Next
From: Michael Paquier
Date:
Subject: Re: Password identifiers, protocol aging and SCRAM protocol