pg_restore error message
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
Attachments:
0001-pg_restore-failure-message-does-not-provide-filename.patchtext/x-patch; charset=US-ASCII; name=0001-pg_restore-failure-message-does-not-provide-filename.patchDownload+1-2
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
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
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
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