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
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 |