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-12 15:13:38
Message-ID: 3100396.1602515618@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:
> On Mon, Oct 12, 2020 at 5:27 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Michael Paquier <michael(at)paquier(dot)xyz> writes:
>>> Why are we forcing errno=ENOENT here? Wouldn't it be correct to use
>>> _dosmaperr(GetLastError()) to get the correct errno?

>> Fair question. Juan, was there some good reason not to look at
>> GetLastError() in this step?

> Uhm, a good question indeed, forcing errno serves no purpose there.

OK, changed.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-10-12 15:21:28 Re: BUG #16667: COMMIT AND CHAIN does not udpates database metrics ie. xact_commit
Previous Message Tom Lane 2020-10-12 14:42:27 Re: BUG #16666: Slight memory leak when running pg_ctl reload

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-10-12 16:00:45 Bizarre coding in recovery target GUC management
Previous Message Shinoda, Noriyoshi (PN Japan A&PS Delivery) 2020-10-12 14:45:04 RE: Resetting spilled txn statistics in pg_stat_replication