diff options
| author | Thomas Munro <tmunro@postgresql.org> | 2023-03-15 13:17:18 +1300 |
|---|---|---|
| committer | Thomas Munro <tmunro@postgresql.org> | 2023-03-15 13:24:47 +1300 |
| commit | d41a178b3a7ac0c2ca16f70129899ddabc2ce468 (patch) | |
| tree | 97b1cc6c3043dd095627d223ee5ad22fcbb10650 /src/backend/executor/execReplication.c | |
| parent | b081fe4199b69dc561f7d31c6a82b3ad996f657f (diff) | |
| download | postgresql-d41a178b3a7ac0c2ca16f70129899ddabc2ce468.tar.gz postgresql-d41a178b3a7ac0c2ca16f70129899ddabc2ce468.zip | |
Fix waitpid() emulation on Windows.
Our waitpid() emulation didn't prevent a PID from being recycled by the
OS before the call to waitpid(). The postmaster could finish up
tracking more than one child process with the same PID, and confuse
them.
Fix, by moving the guts of pgwin32_deadchild_callback() into waitpid(),
so that resources are released synchronously. The process and PID
continue to exist until we close the process handle, which only happens
once we're ready to adjust our book-keeping of running children.
This seems to explain a couple of failures on CI. It had never been
reported before, despite the code being as old as the Windows port.
Perhaps Windows started recycling PIDs more rapidly, or perhaps timing
changes due to commit 7389aad6 made it more likely to break.
Thanks to Alexander Lakhin for analysis and Andres Freund for tracking
down the root cause.
Back-patch to all supported branches.
Reported-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/20230208012852.bvkn2am4h4iqjogq%40awork3.anarazel.de
Diffstat (limited to 'src/backend/executor/execReplication.c')
0 files changed, 0 insertions, 0 deletions