Re: pg_dump/pg_restore: Fix stdin/stdout handling of custom format on Win32

From: Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Daniel Watzinger <daniel(dot)watzinger(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump/pg_restore: Fix stdin/stdout handling of custom format on Win32
Date: 2023-03-13 16:49:41
Message-ID: CAC+AXB3UBN4ivbuu6Fn73HN3mgdhJF04_0U-nRLU1KjsyaadRA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 10, 2023 at 2:37 AM Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-03-13 17:35:28 Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name
Previous Message Jeff Davis 2023-03-13 15:31:46 Re: ICU locale validation / canonicalization