Re: Tracking wait event for latches

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Tracking wait event for latches
Дата
Msg-id CAEepm=0X6WiRR5pr9if=_n9=s8XPgG688Wee0tGnR7jWt=h8RA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Tracking wait event for latches  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Tracking wait event for latches  (Michael Paquier <michael.paquier@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Rafia Sabih
Дата:
Сообщение: "Re: Question about grant create on database and pg_dump/pg_dumpall
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Password identifiers, protocol aging and SCRAM protocol