• Tom Lane's avatar
    Fix race condition in our Windows signal emulation. · 28e6a2fd
    Tom Lane authored
    pg_signal_dispatch_thread() responded to the client (signal sender)
    and disconnected the pipe before actually setting the shared variables
    that make the signal visible to the backend process's main thread.
    In the worst case, it seems, effective delivery of the signal could be
    postponed for as long as the machine has any other work to do.
    
    To fix, just move the pg_queue_signal() call so that we do it before
    responding to the client.  This essentially makes pgkill() synchronous,
    which is a stronger guarantee than we have on Unix.  That may be
    overkill, but on the other hand we have not seen comparable timing bugs
    on any Unix platform.
    
    While at it, add some comments to this sadly underdocumented code.
    
    Problem diagnosis and fix by Amit Kapila; I just added the comments.
    
    Back-patch to all supported versions, as it appears that this can cause
    visible NOTIFY timing oddities on all of them, and there might be
    other misbehavior due to slow delivery of other signals.
    
    Discussion: https://postgr.es/m/32745.1575303812@sss.pgh.pa.us
    28e6a2fd
signal.c 10.6 KB