Re: pg_dump, gzwrite, and errno

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

In response to

Responses

Browse pgsql-hackers by date

  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