Re: BUG #15858: could not stat file - over 4GB

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Emil Iggland <emil(at)iggland(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15858: could not stat file - over 4GB
Date: 2020-10-10 17:42:58
Message-ID: 2920041.1602351778@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= <juanjo(dot)santamaria(at)gmail(dot)com> writes:
> If the file does not exist there is no need to call _dosmaperr() and log
> the error.

I concur with Michael that it's inappropriate to make an end run around
_dosmaperr() here. If you think that the DEBUG5 logging inside that
is inappropriate, you should propose removing it outright.

Pushed the rest of this.

(pgindent behaved differently around PFN_NTQUERYINFORMATIONFILE today
than it did yesterday. No idea why.)

> The meaningful error should come from the previous call, and an error from
> CloseHandle() could mask it. Not sure it makes a difference anyhow.

Would CloseHandle() really touch errno at all? But this way is
certainly safer, so done.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Juan José Santamaría Flecha 2020-10-10 19:00:27 Re: BUG #15858: could not stat file - over 4GB
Previous Message Pavel Stehule 2020-10-10 14:56:32 Re: BUG #16665: Segmentation fault

Browse pgsql-hackers by date

  From Date Subject
Next Message Juan José Santamaría Flecha 2020-10-10 19:00:27 Re: BUG #15858: could not stat file - over 4GB
Previous Message Pavel Stehule 2020-10-10 16:30:26 Re: Make LANGUAGE SQL the default