| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> | 
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)postgresql(dot)org, Kunshchikov Vladimir <Vladimir(dot)Kunshchikov(at)infotecs(dot)ru> | 
| Subject: | Re: pg_dump, gzwrite, and errno | 
| Date: | 2020-06-18 21:30:18 | 
| Message-ID: | 1597085.1592515818@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2020-Jun-11, Justin Pryzby wrote:
>> --- a/src/bin/pg_dump/pg_backup_directory.c
>> +++ b/src/bin/pg_dump/pg_backup_directory.c
>> @@ -347,8 +347,12 @@ _WriteData(ArchiveHandle *AH, const void *data, size_t dLen)
>>         lclContext *ctx = (lclContext *) AH->formatData;
>>  
>>         if (dLen > 0 && cfwrite(data, dLen, ctx->dataFH) != dLen)
>> +       {
>> +               if (errno == 0)
>> +                       errno = ENOSPC;
>>                 fatal("could not write to output file: %s",
>>                           get_cfp_error(ctx->dataFH));
>> +       }
>>  }
> This seems correct to me.
Surely it's insufficient as-is, because there is no reason to suppose
that errno is zero at entry.  You'd need to set errno = 0 first.
Also it's fairly customary in our sources to include a comment about
this machination; so the full ritual is usually more like
    errno = 0;
    if (pg_pwrite(fd, data, len, xlrec->offset) != len)
    {
        /* if write didn't set errno, assume problem is no disk space */
        if (errno == 0)
            errno = ENOSPC;
        ereport ...
> (I spent a long time looking at zlib sources
> to convince myself that it does work with compressed files too)
Yeah, it's not obvious that gzwrite has the same behavior w.r.t. errno
as a plain write.  But there's not much we can do to improve matters
if it does not, so we might as well assume it does.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2020-06-18 22:19:52 | Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks) | 
| Previous Message | Bossart, Nathan | 2020-06-18 21:26:50 | Re: Add support for INDEX_CLEANUP and TRUNCATE to vacuumdb |