In libpq for Windows, call WSAStartup once and WSACleanup not at all.
authorTom Lane <[email protected]>
Mon, 19 Oct 2020 15:23:52 +0000 (11:23 -0400)
committerTom Lane <[email protected]>
Mon, 19 Oct 2020 15:23:52 +0000 (11:23 -0400)
commit6acc31a201d84ff795b0d0f5a4b3a0ec1730347a
tree58684a064a4c8660a06b28135500086f1431263a
parent3798b4fe73b97147f67847bcb611283acd9fb0d4
In libpq for Windows, call WSAStartup once and WSACleanup not at all.

The Windows documentation insists that every WSAStartup call should
have a matching WSACleanup call.  However, if that ever had actual
relevance, it wasn't in this century.  Every remotely-modern Windows
kernel is capable of cleaning up when a process exits without doing
that, and must be so to avoid resource leaks in case of a process
crash.  Moreover, Postgres backends have done WSAStartup without
WSACleanup since commit 4cdf51e64 in 2004, and we've never seen any
indication of a problem with that.

libpq's habit of doing WSAStartup during connection start and
WSACleanup during shutdown is also rather inefficient, since a
series of non-overlapping connection requests leads to repeated,
quite expensive DLL unload/reload cycles.  We document a workaround
for that (having the application call WSAStartup for itself), but
that's just a kluge.  It's also worth noting that it's far from
uncommon for applications to exit without doing PQfinish, and
we've not heard reports of trouble from that either.

However, the real reason for acting on this is that recent
experiments by Alexander Lakhin show that calling WSACleanup
during PQfinish is triggering the symptom we occasionally see
that a process using libpq fails to emit expected stdio output.

Therefore, let's change libpq so that it calls WSAStartup only
once per process, during the first connection attempt, and never
calls WSACleanup at all.

While at it, get rid of the only other WSACleanup call in our code
tree, in pg_dump/parallel.c; that presumably is equally useless.

Back-patch of HEAD commit 7d00a6b2d.

Discussion: https://postgr.es/m/ac976d8c-03df-d6b8-025c-15a2de8d9af1@postgrespro.ru
doc/src/sgml/libpq.sgml
src/bin/pg_dump/parallel.c
src/interfaces/libpq/fe-connect.c