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
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? |