Re: Dereference before NULL check (src/backend/storage/ipc/latch.c) - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)
Date
Msg-id 20201104.100928.2164321889253965531.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)  (Ranier Vilela <ranier.vf@gmail.com>)
List pgsql-hackers
At Tue, 3 Nov 2020 20:44:23 +1300, Thomas Munro <thomas.munro@gmail.com> wrote in 
> On Tue, Nov 3, 2020 at 12:50 AM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> > With the fix patch, it changes to:
> >
> > [16632] LOG:  FALSE LATCH: 0000000000000000
> 
> Nice repo.  But is it OK to not reset the Win32 event in this case?
> Does it still work correctly if you wait on the latch after that
> happened, and perhaps after the PG latch is reset?

I'm not sure what is the point of the question, but the previous patch
doesn't omit resetting the Win32-event in that case.  In the same way
with other implements of the same function, it resets the trigger that
woke up the process since the trigger is no longer needed even if we
are not waiting on it.

If we call WaitLatch(OrSocket) that waits on the latch, it immediately
returns because the latch is set. If we called ResetLatch before the
next call to WaitLatch(), it correctly waits on a trigger to be
pulled.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Fix brin_form_tuple to properly detoast data
Next
From: Tom Lane
Date:
Subject: Re: -O switch