Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: thomas(dot)munro(at)gmail(dot)com
Cc: ranier(dot)vf(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)
Date: 2020-11-04 01:09:28
Message-ID: 20201104.100928.2164321889253965531.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 3 Nov 2020 20:44:23 +1300, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote in
> On Tue, Nov 3, 2020 at 12:50 AM Kyotaro Horiguchi
> <horikyota(dot)ntt(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-11-04 01:10:45 Re: -O switch
Previous Message Tomas Vondra 2020-11-04 01:05:44 Fix brin_form_tuple to properly detoast data