Re: pg_receivewal.exe unhandled exception in zlib1.dll

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_receivewal.exe unhandled exception in zlib1.dll
Date: 2022-02-14 06:31:42
Message-ID: Ygn3TqQM3DpnaX5Z@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-02-14 06:40:23 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Previous Message Tom Lane 2022-02-14 06:25:18 Re: How did queensnake corrupt zic.o?