Re: hash join error improvement (old)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: hash join error improvement (old)
Дата
Msg-id 31139.1590449592@sss.pgh.pa.us
обсуждение исходный текст
Ответ на hash join error improvement (old)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: hash join error improvement (old)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> I recently noticed this in a customer log file:
>   ERROR:  could not read from hash-join temporary file: Success
> The problem is we're reporting with %m when the problem is a partial
> read or write.
> I propose the attached patch to solve it: report "wrote only X of X
> bytes".  This caused a lot of other trouble, the cause of which I've
> been unable to pinpoint as yet.  But in the meantime, this is already a
> small improvement.

+1 for the idea, but there's still one small problem with what you did
here: errcode_for_file_access() looks at errno, which we can presume
will not have a relevant value in the "wrote only %d bytes" paths.

Most places that are taking pains to deal with this scenario
do something like

    errno = 0;
    if (write(fd, data, len, xlrec->offset) != len)
    {
        /* if write didn't set errno, assume problem is no disk space */
        if (errno == 0)
            errno = ENOSPC;
        ereport(ERROR,
                (errcode_for_file_access(),
                 errmsg("could not write to file \"%s\": %m", path)));
    }

I don't mind if you want to extend that paradigm to also use "wrote only
%d bytes" wording, but the important point is to get the SQLSTATE set on
the basis of ENOSPC rather than whatever random value errno will have
otherwise.

            regards, tom lane



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: hash join error improvement (old)
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: WAL reader APIs and WAL segment open/close callbacks