From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: More consistency for some file-related error message |
Date: | 2018-07-20 06:41:08 |
Message-ID: | 20180720064108.GF7023@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 19, 2018 at 12:33:30PM +0900, Michael Paquier wrote:
> On Wed, Jul 18, 2018 at 11:24:05PM -0400, Tom Lane wrote:
>> read() is required by spec to set errno when returning a negative result.
>> I think the previous coding paid attention to errno regardless of the sign
>> of the result, which would justify pre-zeroing it ... but the new coding
>> definitely doesn't.
>
> Yes, my point is a bit different though.. Do you think that we need to
> bother about the case where errno is not 0 before calling read(), in the
> case where it returns a positive result? This would mean that errno
> would still have a previous errno set, still it returned a number of
> bytes read. For the code paths discussed here that visibly does not
> matter so you are right, we could remove them, still patterns get easily
> copy-pasted around...
Okay, I just looked again at this point, and among the new messages only
what's in XLogFileCopy has been bothering setting errno to 0 (see
811b6e3), so let's remove it in this case.
Thoughts about the previous patch set?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Nikhil Sontakke | 2018-07-20 06:43:19 | Re: [HACKERS] logical decoding of two-phase transactions |
Previous Message | Thomas Munro | 2018-07-20 05:22:17 | Re: Possible performance regression in version 10.1 with pgbench read-write tests. |