pg.ddx.io  pgsql-committers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
pgsql: Fix lost Windows socket EOF events.
7+ messages / 1 participants
[nested] [flat]

* pgsql: Fix lost Windows socket EOF events.
@ 2024-07-13 04:14  Thomas Munro <tmunro@postgresql.org>
  0 siblings, 0 replies; 7+ messages in thread

From: Thomas Munro @ 2024-07-13 04:14 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix lost Windows socket EOF events.

Winsock only signals an FD_CLOSE event once if the other end of the
socket shuts down gracefully.  Because each WaitLatchOrSocket() call
constructs and destroys a new event handle every time, with unlucky
timing we can lose it and hang.  We get away with this only if the other
end disconnects non-gracefully, because FD_CLOSE is repeatedly signaled
in that case.

To fix this design flaw in our Windows socket support fundamentally,
we'd probably need to rearchitect it so that a single event handle
exists for the lifetime of a socket, or switch to completely different
multiplexing or async I/O APIs.  That's going to be a bigger job
and probably wouldn't be back-patchable.

This brute force kludge closes the race by explicitly polling with
MSG_PEEK before sleeping.

Back-patch to all supported releases.  This should hopefully clear up
some random build farm and CI hang failures reported over the years.  It
might also allow us to try using graceful shutdown in more places again
(reverted in commit 29992a6) to fix instability in the transmission of
FATAL error messages, but that isn't done by this commit.

Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Tested-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/176008.1715492071%40sss.pgh.pa.us

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/a8458f508a7a441242e148f008293128676df003

Modified Files
--------------
src/backend/storage/ipc/latch.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Fix lost Windows socket EOF events.
@ 2024-07-13 04:14  Thomas Munro <tmunro@postgresql.org>
  0 siblings, 0 replies; 7+ messages in thread

From: Thomas Munro @ 2024-07-13 04:14 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix lost Windows socket EOF events.

Winsock only signals an FD_CLOSE event once if the other end of the
socket shuts down gracefully.  Because each WaitLatchOrSocket() call
constructs and destroys a new event handle every time, with unlucky
timing we can lose it and hang.  We get away with this only if the other
end disconnects non-gracefully, because FD_CLOSE is repeatedly signaled
in that case.

To fix this design flaw in our Windows socket support fundamentally,
we'd probably need to rearchitect it so that a single event handle
exists for the lifetime of a socket, or switch to completely different
multiplexing or async I/O APIs.  That's going to be a bigger job
and probably wouldn't be back-patchable.

This brute force kludge closes the race by explicitly polling with
MSG_PEEK before sleeping.

Back-patch to all supported releases.  This should hopefully clear up
some random build farm and CI hang failures reported over the years.  It
might also allow us to try using graceful shutdown in more places again
(reverted in commit 29992a6) to fix instability in the transmission of
FATAL error messages, but that isn't done by this commit.

Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Tested-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/176008.1715492071%40sss.pgh.pa.us

Branch
------
REL_17_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/3c1c82d4066e19a2841fb5f0529452de0d4d65b2

Modified Files
--------------
src/backend/storage/ipc/latch.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Fix lost Windows socket EOF events.
@ 2024-07-13 04:14  Thomas Munro <tmunro@postgresql.org>
  0 siblings, 0 replies; 7+ messages in thread

From: Thomas Munro @ 2024-07-13 04:14 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix lost Windows socket EOF events.

Winsock only signals an FD_CLOSE event once if the other end of the
socket shuts down gracefully.  Because each WaitLatchOrSocket() call
constructs and destroys a new event handle every time, with unlucky
timing we can lose it and hang.  We get away with this only if the other
end disconnects non-gracefully, because FD_CLOSE is repeatedly signaled
in that case.

To fix this design flaw in our Windows socket support fundamentally,
we'd probably need to rearchitect it so that a single event handle
exists for the lifetime of a socket, or switch to completely different
multiplexing or async I/O APIs.  That's going to be a bigger job
and probably wouldn't be back-patchable.

This brute force kludge closes the race by explicitly polling with
MSG_PEEK before sleeping.

Back-patch to all supported releases.  This should hopefully clear up
some random build farm and CI hang failures reported over the years.  It
might also allow us to try using graceful shutdown in more places again
(reverted in commit 29992a6) to fix instability in the transmission of
FATAL error messages, but that isn't done by this commit.

Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Tested-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/176008.1715492071%40sss.pgh.pa.us

Branch
------
REL_16_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/a622095bcc4d12c5ff3caa02756a8ab2e0813ed3

Modified Files
--------------
src/backend/storage/ipc/latch.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Fix lost Windows socket EOF events.
@ 2024-07-13 04:15  Thomas Munro <tmunro@postgresql.org>
  0 siblings, 0 replies; 7+ messages in thread

From: Thomas Munro @ 2024-07-13 04:15 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix lost Windows socket EOF events.

Winsock only signals an FD_CLOSE event once if the other end of the
socket shuts down gracefully.  Because each WaitLatchOrSocket() call
constructs and destroys a new event handle every time, with unlucky
timing we can lose it and hang.  We get away with this only if the other
end disconnects non-gracefully, because FD_CLOSE is repeatedly signaled
in that case.

To fix this design flaw in our Windows socket support fundamentally,
we'd probably need to rearchitect it so that a single event handle
exists for the lifetime of a socket, or switch to completely different
multiplexing or async I/O APIs.  That's going to be a bigger job
and probably wouldn't be back-patchable.

This brute force kludge closes the race by explicitly polling with
MSG_PEEK before sleeping.

Back-patch to all supported releases.  This should hopefully clear up
some random build farm and CI hang failures reported over the years.  It
might also allow us to try using graceful shutdown in more places again
(reverted in commit 29992a6) to fix instability in the transmission of
FATAL error messages, but that isn't done by this commit.

Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Tested-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/176008.1715492071%40sss.pgh.pa.us

Branch
------
REL_15_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/5546a834cc6fa49057356eb90ecbd9ee12d7d58a

Modified Files
--------------
src/backend/storage/ipc/latch.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Fix lost Windows socket EOF events.
@ 2024-07-13 04:15  Thomas Munro <tmunro@postgresql.org>
  0 siblings, 0 replies; 7+ messages in thread

From: Thomas Munro @ 2024-07-13 04:15 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix lost Windows socket EOF events.

Winsock only signals an FD_CLOSE event once if the other end of the
socket shuts down gracefully.  Because each WaitLatchOrSocket() call
constructs and destroys a new event handle every time, with unlucky
timing we can lose it and hang.  We get away with this only if the other
end disconnects non-gracefully, because FD_CLOSE is repeatedly signaled
in that case.

To fix this design flaw in our Windows socket support fundamentally,
we'd probably need to rearchitect it so that a single event handle
exists for the lifetime of a socket, or switch to completely different
multiplexing or async I/O APIs.  That's going to be a bigger job
and probably wouldn't be back-patchable.

This brute force kludge closes the race by explicitly polling with
MSG_PEEK before sleeping.

Back-patch to all supported releases.  This should hopefully clear up
some random build farm and CI hang failures reported over the years.  It
might also allow us to try using graceful shutdown in more places again
(reverted in commit 29992a6) to fix instability in the transmission of
FATAL error messages, but that isn't done by this commit.

Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Tested-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/176008.1715492071%40sss.pgh.pa.us

Branch
------
REL_14_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/894b497ac91dcac79f85d1b4bae7f640788b1004

Modified Files
--------------
src/backend/storage/ipc/latch.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Fix lost Windows socket EOF events.
@ 2024-07-13 04:15  Thomas Munro <tmunro@postgresql.org>
  0 siblings, 0 replies; 7+ messages in thread

From: Thomas Munro @ 2024-07-13 04:15 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix lost Windows socket EOF events.

Winsock only signals an FD_CLOSE event once if the other end of the
socket shuts down gracefully.  Because each WaitLatchOrSocket() call
constructs and destroys a new event handle every time, with unlucky
timing we can lose it and hang.  We get away with this only if the other
end disconnects non-gracefully, because FD_CLOSE is repeatedly signaled
in that case.

To fix this design flaw in our Windows socket support fundamentally,
we'd probably need to rearchitect it so that a single event handle
exists for the lifetime of a socket, or switch to completely different
multiplexing or async I/O APIs.  That's going to be a bigger job
and probably wouldn't be back-patchable.

This brute force kludge closes the race by explicitly polling with
MSG_PEEK before sleeping.

Back-patch to all supported releases.  This should hopefully clear up
some random build farm and CI hang failures reported over the years.  It
might also allow us to try using graceful shutdown in more places again
(reverted in commit 29992a6) to fix instability in the transmission of
FATAL error messages, but that isn't done by this commit.

Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Tested-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/176008.1715492071%40sss.pgh.pa.us

Branch
------
REL_13_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/3554d841d21624aae72c836f46af09b65b30e890

Modified Files
--------------
src/backend/storage/ipc/latch.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Fix lost Windows socket EOF events.
@ 2024-07-13 04:15  Thomas Munro <tmunro@postgresql.org>
  0 siblings, 0 replies; 7+ messages in thread

From: Thomas Munro @ 2024-07-13 04:15 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix lost Windows socket EOF events.

Winsock only signals an FD_CLOSE event once if the other end of the
socket shuts down gracefully.  Because each WaitLatchOrSocket() call
constructs and destroys a new event handle every time, with unlucky
timing we can lose it and hang.  We get away with this only if the other
end disconnects non-gracefully, because FD_CLOSE is repeatedly signaled
in that case.

To fix this design flaw in our Windows socket support fundamentally,
we'd probably need to rearchitect it so that a single event handle
exists for the lifetime of a socket, or switch to completely different
multiplexing or async I/O APIs.  That's going to be a bigger job
and probably wouldn't be back-patchable.

This brute force kludge closes the race by explicitly polling with
MSG_PEEK before sleeping.

Back-patch to all supported releases.  This should hopefully clear up
some random build farm and CI hang failures reported over the years.  It
might also allow us to try using graceful shutdown in more places again
(reverted in commit 29992a6) to fix instability in the transmission of
FATAL error messages, but that isn't done by this commit.

Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Tested-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/176008.1715492071%40sss.pgh.pa.us

Branch
------
REL_12_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/ba9fcac7209d884a63cc3e434914132f1ee0dfd2

Modified Files
--------------
src/backend/storage/ipc/latch.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread


end of thread, other threads:[~2024-07-13 04:15 UTC | newest]

Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-07-13 04:14 pgsql: Fix lost Windows socket EOF events. Thomas Munro <tmunro@postgresql.org>
2024-07-13 04:14 pgsql: Fix lost Windows socket EOF events. Thomas Munro <tmunro@postgresql.org>
2024-07-13 04:14 pgsql: Fix lost Windows socket EOF events. Thomas Munro <tmunro@postgresql.org>
2024-07-13 04:15 pgsql: Fix lost Windows socket EOF events. Thomas Munro <tmunro@postgresql.org>
2024-07-13 04:15 pgsql: Fix lost Windows socket EOF events. Thomas Munro <tmunro@postgresql.org>
2024-07-13 04:15 pgsql: Fix lost Windows socket EOF events. Thomas Munro <tmunro@postgresql.org>
2024-07-13 04:15 pgsql: Fix lost Windows socket EOF events. Thomas Munro <tmunro@postgresql.org>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox