On Fri, Jul 20, 2018 at 03:41:08PM +0900, Michael Paquier wrote:
> 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.
So, I have been through the patch set once ag
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, w
On Thu, Jul 19, 2018 at 02:05:51PM +0900, Kyotaro HORIGUCHI wrote:
> Agreed to it's not necessary and a developer ought to know about
> the errno behavior. However, I can sympathize with Michael.
I am fine to remove them if folks here push for that.
> CopyGetData has a variant of it.
>
> |
Hello.
At Thu, 19 Jul 2018 12:33:30 +0900, Michael Paquier wrote
in <2018071900.gh3...@paquier.xyz>
> 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 errn
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
Michael Paquier writes:
> On Wed, Jul 18, 2018 at 10:57:16AM -0400, Tom Lane wrote:
>> BTW, isn't the initial "errno = 0" dead code now?
> Hm. I have not bothered touching those as it could be possible that
> read() may not initialize errno to 0, so errno would remain set to any
> previous value
On Wed, Jul 18, 2018 at 10:57:16AM -0400, Tom Lane wrote:
> +1.
Okay, thanks. I can always get that pushed first if there are no
objections. More can be always done, but that's already a nice cut.
> The short-read ereport has no errcode() call, meaning it will report
> XX000, which seems like i
Michael Paquier writes:
> While looking at the source code for more consistency work with error
> messages, I have bumped into a couple of messages which could be
> simplified, as those include in the name of the file manipulated
> basically the same information as the context added.
> I have fin
Hi all,
While looking at the source code for more consistency work with error
messages, I have bumped into a couple of messages which could be
simplified, as those include in the name of the file manipulated
basically the same information as the context added.
I have finished with the attached.
