Broken order-of-operations in parallel query latch manipulation

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Broken order-of-operations in parallel query latch manipulation
Дата
Msg-id
1661.1469996911@sss.pgh.pa.us
Список
Дерево обсуждения
Broken order-of-operations in parallel query latch manipulation Tom Lane <tgl@sss.pgh.pa.us>
Re: Broken order-of-operations in parallel query latch manipulation Amit Kapila <amit.kapila16@gmail.com>
Re: Broken order-of-operations in parallel query latch manipulation Tom Lane <tgl@sss.pgh.pa.us>
Re: Broken order-of-operations in parallel query latch manipulation Amit Kapila <amit.kapila16@gmail.com>
Both shm_mq.c and nodeGather.c contain instances of this coding pattern:
           WaitLatch(MyLatch, WL_LATCH_SET, 0);           CHECK_FOR_INTERRUPTS();           ResetLatch(MyLatch);

I believe this is wrong and the CHECK_FOR_INTERRUPTS needs to be before
or after the two latch operations.  As-is, if the reason somebody set
our latch was to get us to notice that a CHECK_FOR_INTERRUPTS condition
happened, there's a race condition where we'd fail to realize that.
Other places such as ProcWaitForSignal() do it that way; only recently
introduced (and unproven in the field) code has it like this.

Anyone want to argue it's okay as-is?
		regards, tom lane


В списке pgsql-hackers по дате отправления
От: Peter Geoghegan
Дата:
От: Greg Stark
Дата:
FAQ