Horton

Thread

Commits

  1. pg_restore: Provide file name with one failure message

  1. pg_restore error message

    Euler Taveira <euler.taveira@2ndquadrant.com> — 2020-05-07T21:54:06Z

    Hi,

While investigating a pg_restore error, I stumbled upon a message that is
not so useful.

pg_restore: error: could not close data file: No such file or directory

Which file? File name should be printed too like in the error check for
cfopen_read a few lines above.

Regards,

-- 
Euler Taveira                 http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  2. Re: pg_restore error message

    Ranier Vilela <ranier.vf@gmail.com> — 2020-05-07T22:17:14Z

    Em qui., 7 de mai. de 2020 às 18:54, Euler Taveira <
euler.taveira@2ndquadrant.com> escreveu:

> Hi,
>
> While investigating a pg_restore error, I stumbled upon a message that is
> not so useful.
>
> pg_restore: error: could not close data file: No such file or directory
>
> Which file? File name should be printed too like in the error check for
> cfopen_read a few lines above.
>
Can suggest improvements?

1. free (398 line) must be pg_free(buf)';
2. %m, is a format to parameter, right?
    But what parameter? Both fatal call, do not pass this parameter, or is
it implied?

regards,
Ranier Vilela

  3. Re: pg_restore error message

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2020-05-08T23:42:30Z

    On 2020-May-07, Euler Taveira wrote:

> While investigating a pg_restore error, I stumbled upon a message that is
> not so useful.
> 
> pg_restore: error: could not close data file: No such file or directory
> 
> Which file? File name should be printed too like in the error check for
> cfopen_read a few lines above.

Thanks for reporting.  Fix pushed to 9.5 and up.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  4. Re: pg_restore error message

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2020-05-08T23:45:16Z

    On 2020-May-07, Ranier Vilela wrote:

> Can suggest improvements?
> 
> 1. free (398 line) must be pg_free(buf)';

Yeah, there's a lot of frontend code that uses free() instead of
pg_free().  There are too many of these that worrying about a single one
would not improve things much.  I guess we could convert them all, but I
don't see much point.

> 2. %m, is a format to parameter, right?
>     But what parameter? Both fatal call, do not pass this parameter, or is
> it implied?

%m is an implied "strerror(errno)", implemented by our snprintf
replacement.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  5. Re: pg_restore error message

    Michael Paquier <michael@paquier.xyz> — 2020-05-09T07:39:08Z

    On Fri, May 08, 2020 at 07:45:16PM -0400, Alvaro Herrera wrote:
> Yeah, there's a lot of frontend code that uses free() instead of
> pg_free().  There are too many of these that worrying about a single one
> would not improve things much.  I guess we could convert them all, but I
> don't see much point.

Doing a hard switch would have the disadvantage to create more
problems when back-patching.  Even if such conflicts would be I guess
simple enough to address, that's less to worry about.  I think however
that there is a point in switching to a more PG-like API if reworking
an area of the code for a new feature or a refactoring, but this is a
case-by-case judgement usually.

>> 2. %m, is a format to parameter, right?
>>     But what parameter? Both fatal call, do not pass this parameter, or is
>> it implied?
> 
> %m is an implied "strerror(errno)", implemented by our snprintf
> replacement.

Originally, %m is a glibc extension, which has been added recently in
our port in src/port/snprintf.c as of d6c55de.
--
Michael