Chao Li <[email protected]> 于2026年2月24日周二 14:29写道：
> Hi,
>
> I just noticed this while reviewing patch [1]. It looks like this is
> caused by a simple typo.
>
> In ProcWakeup():
> ```
> PGPROC *
> ProcWakeup(PGPROC *proc, ProcWaitStatus waitStatus)
> {
> PGPROC *retProc;
>
> /* Proc should be sleeping ... */
> if (proc->links.prev == NULL ||
> proc->links.next == NULL)
> return NULL;
> Assert(proc->waitStatus == PROC_WAIT_STATUS_WAITING);
>
> /* Save next process before we zap the list link */
> retProc = (PGPROC *) proc->links.next;
>
> /* Remove process from wait queue */
> SHMQueueDelete(&(proc->links));
> (proc->waitLock->waitProcs.size)--;
>
> /* Clean up process' state and pass it the ok/fail signal */
> proc->waitLock = NULL;
> proc->waitProcLock = NULL;
> proc->waitStatus = waitStatus;
> pg_atomic_write_u64(&MyProc->waitStart, 0); <== Here, it should
> operate on proc
>
> /* And awaken it */
> SetLatch(&proc->procLatch);
>
> return retProc;
> }
> ```
>
> Since this function is clearly operating on the parameter proc, the only
> statement that touches MyProc looks suspicious. It should reset
> proc->waitStart, not MyProc->waitStart.
>
> As written, it will incorrectly clear the caller’s waitStart instead of
> the awakened backend’s, potentially leaving a stale waitStart value in the
> target PGPROC.
>
> [1]
> https://postgr.es/m/cahgqgwgw4lhnwogqt3nbw3uwy8gl94_mb4t39wfr4_vgopu...@mail.gmail.com
>
> Best regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
>
>
>
>
>
>
>
Hi ,
The fix looks correct to me. I applied it locally and build and "make
check" passed from my side.
Regards,
ji xu
