Re: pg_receivewal.exe unhandled exception in zlib1.dll - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_receivewal.exe unhandled exception in zlib1.dll
Date
Msg-id Ygn3TqQM3DpnaX5Z@paquier.xyz
Whole thread Raw
In response to Re: pg_receivewal.exe unhandled exception in zlib1.dll  (Andres Freund <andres@anarazel.de>)
Responses Re: pg_receivewal.exe unhandled exception in zlib1.dll  (Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>)
List pgsql-hackers
On Fri, Feb 11, 2022 at 07:50:44AM -0800, Andres Freund wrote:
> On 2022-02-11 16:33:11 +0100, Juan José Santamaría Flecha wrote:
>> The problem comes from the file descriptor passed to gzdopen() in
>> 'src/bin/pg_basebackup/walmethods.c'. Using gzopen() instead, solves the
>> issue without ifdefing for WIN32. Please find attached a patch for so.

This looks wrong to me as gzclose() would close() the file descriptor
we pass in via gzdopen(), and some code paths of walmethods.c rely on
this assumption so this would leak fds on repeated errors.

> I hit this as well. The problem is really caused by using a debug build of
> postgres vs a production build of zlib. The use different C runtimes, with
> different file descriptors. A lot of resources in the windows world are
> unfortunately tied to the C runtime and that there can multiple C runtimes in
> a single process.

It may be worth warning about that at build time, or just document the
matter perhaps?  I don't recall seeing any MSIs related to zlib that
have compile with the debug options.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: How did queensnake corrupt zic.o?
Next
From: Michael Paquier
Date:
Subject: Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set