On Sun, Jun 24, 2018 at 09:23:50PM +0900, Michael Paquier wrote:
> On Sun, Jun 24, 2018 at 09:22:01AM +0530, Ashutosh Sharma wrote:
>> Okay, I too had a quick look into the source code to see if there are
>> still some places where we could have missed to set an errno to ENOSPC
>> in case of write
On Sun, Jun 24, 2018 at 09:22:01AM +0530, Ashutosh Sharma wrote:
> Okay, I too had a quick look into the source code to see if there are
> still some places where we could have missed to set an errno to ENOSPC
> in case of write system call failure but, couldn't find any such place
> in the code. T
On Sat, Jun 23, 2018 at 6:43 PM, Michael Paquier wrote:
> On Fri, Jun 22, 2018 at 03:45:33PM +0530, Ashutosh Sharma wrote:
>> Okay, thanks for the confirmation. Few of them are also there in
>> origin.c and snapbuild.c files.
>
> Thanks Ashutosh. I have been reviewing the whole tree and I found m
On Fri, Jun 22, 2018 at 11:15:53AM -0400, Alvaro Herrera wrote:
> I wondered for a bit if it would be a better idea to have
> CloseTransientFile restore the existing errno if there is any and close
> works fine -- when I noticed that that function itself says that caller
> should check errno for cl
On Fri, Jun 22, 2018 at 03:45:33PM +0530, Ashutosh Sharma wrote:
> Okay, thanks for the confirmation. Few of them are also there in
> origin.c and snapbuild.c files.
Thanks Ashutosh. I have been reviewing the whole tree and I found more
places where this is missing, like rewriteheap.c, reorderbuf
Hi,
On 2018-06-22 11:15:53 -0400, Alvaro Herrera wrote:
> I don't understand the logic in RestoreSlotFromDisk that fsync the file
> prior to reading it. What are we protecting against?
we could previously have crashed before fsyncing. But we can only rely
on slot contents being durable if we fsy
On 2018-Jun-22, Michael Paquier wrote:
> A couple of places use CloseTransientFile without bothering much that
> this can overwrite errno. I was tempted in keeping errno saved and kept
> if set to a non-zero value, but refrained from doing so as some callers
> may rely on the existing behavior, a
On Fri, Jun 22, 2018 at 2:44 PM, Michael Paquier wrote:
> On Fri, Jun 22, 2018 at 01:00:45PM +0530, Ashutosh Sharma wrote:
>> It seems like in case of few system calls for e.g. write system call,
>> errno is not set even if the number of bytes written is smaller than
>> the bytes requested and for
On Fri, Jun 22, 2018 at 01:00:45PM +0530, Ashutosh Sharma wrote:
> It seems like in case of few system calls for e.g. write system call,
> errno is not set even if the number of bytes written is smaller than
> the bytes requested and for such cases we explicitly set an errno to
> ENOSPC. Something
Hi,
It seems like in case of few system calls for e.g. write system call,
errno is not set even if the number of bytes written is smaller than
the bytes requested and for such cases we explicitly set an errno to
ENOSPC. Something like this,
/*
* if write didn't se
Hi all,
I have been reviewing the use of errno in the backend code when %m is
used in the logs, and found more places than when I looked at improving
the error messages for read() calls which bloat the errno value because
of intermediate system calls. As the problem is separate and should be
back
11 matches
Mail list logo
