Re: hash join error improvement (old) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: hash join error improvement (old)
Date
Msg-id 31139.1590449592@sss.pgh.pa.us
Whole thread Raw
In response to hash join error improvement (old)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: hash join error improvement (old)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: hash join error improvement (old)
Next
From: Michael Paquier
Date:
Subject: Re: WAL reader APIs and WAL segment open/close callbacks