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: | Raw Message | Whole Thread | 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 |