Re: Incorrect errno used with %m for backend code

Поиск
Список
Период
Сортировка
От Ashutosh Sharma
Тема Re: Incorrect errno used with %m for backend code
Дата
Msg-id CAE9k0P=jJBfZkjSNWi0CqSC7JgCZBLzetFZ7Ng9mF7zoL0pv0A@mail.gmail.com
обсуждение исходный текст
Ответ на Incorrect errno used with %m for backend code  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Incorrect errno used with %m for backend code  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
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 set errno, assume problem is no disk space
                 */
                errno = save_errno ? save_errno : ENOSPC;

Shouldn't we do similar handling in your patch as well or please let
me know if i am missing something here.

On Fri, Jun 22, 2018 at 11:45 AM, Michael Paquier <michael@paquier.xyz> wrote:
> 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-patched, I have preferred beginning a new thread.
>
> 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, and the attached shows better the
> intention.
>
> Attached is a patch with everything I have spotted.  Any opinions or
> thoughts in getting this back-patched?
>
> Thanks,
> --
> Michael


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Continue work on changes to recovery.conf API
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Possible bug in logical replication.