Re: pg_restore: could not close data file: Success

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: hjp-pgsql(at)hjp(dot)at, pgsql-general(at)lists(dot)postgresql(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_restore: could not close data file: Success
Date: 2020-04-16 05:40:09
Message-ID: 20200416054009.GB81957@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Thu, Apr 16, 2020 at 12:08:09PM +0900, Kyotaro Horiguchi wrote:
> I'm surprised to find an old thread about the same issue.
>
> https://www.postgresql.org/message-id/20160307.174354.251049100.horiguchi.kyotaro%40lab.ntt.co.jp
>
> But I don't think it's not acceptable that use fake errno for gzclose,
> but cfclose properly passes-through the error code from gzclose, so it
> is enought that the caller should recognize the difference.

A problem with this patch is that we may forget again to add this
special error handling if more code paths use cfclose().

As of HEAD, there are three code paths where cfclose() is called but
it does not generate an error: two when ending a blob and one when
ending a data file. Perhaps it would make sense to just move all this
error within the routine itself? Note that it would also mean
registering file names in lclContext or equivalent as that's an
important piece of the error message.
--
Michael

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message raf 2020-04-16 07:19:08 Re: timestamp and timestamptz
Previous Message Niels Jespersen 2020-04-16 04:12:46 SV: timestamp and timestamptz

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-04-16 06:01:59 Re: Vacuum o/p with (full 1, parallel 0) option throwing an error
Previous Message Craig Ringer 2020-04-16 05:32:24 Re: Do we need to handle orphaned prepared transactions in the server?