[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    [HACKERS] Broken order-of-operations in parallel query latch manipulation
From:       Tom Lane <tgl () sss ! pgh ! pa ! us>
Date:       2016-07-31 20:28:31
Message-ID: 1661.1469996911 () sss ! pgh ! pa ! us
[Download RAW message or body]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]