Re: pg_dump/pg_restore: Fix stdin/stdout handling of custom format on Win32 - Mailing list pgsql-hackers

From Juan José Santamaría Flecha
Subject Re: pg_dump/pg_restore: Fix stdin/stdout handling of custom format on Win32
Date
Msg-id CAC+AXB3UBN4ivbuu6Fn73HN3mgdhJF04_0U-nRLU1KjsyaadRA@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump/pg_restore: Fix stdin/stdout handling of custom format on Win32  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_dump/pg_restore: Fix stdin/stdout handling of custom format on Win32
List pgsql-hackers

On Fri, Mar 10, 2023 at 2:37 AM Michael Paquier <michael@paquier.xyz> wrote:
On Fri, Mar 10, 2023 at 12:12:37AM +0100, Juan José Santamaría Flecha wrote:
> I've broken the patch in two:
> 1. fixes the detection of unseekable files in checkSeek(), using logic that
> hopefully is backpatchable,
> 2. the improvements on file type detection for stat() proposed by the OP.

I am OK with 0002, so I'll try to get this part backpatched down to
where the implementation of stat() has been added.  I am not
completely sure that 0001 is the right way forward, though,
particularly with the long-term picture..  In the backend, we have one
caller of fseeko() as of read_binary_file(), so we would never pass
down a pipe to that.  However, there could be a risk of some silent
breakages on Windows if some new code relies on that?

There is a total of 11 callers of fseeko() in pg_dump, so rather than
relying on checkSeek() to see if it actually works, I'd like to think
that we should have a central policy to make this code more
bullet-proof in the future.

WFM, making fseek() behaviour more resilient seems like a good improvement overall.

Should we open a new thread to make that part more visible?

Regards,

Juan José Santamaría Flecha

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: ICU locale validation / canonicalization
Next
From: Nathan Bossart
Date:
Subject: Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name