Thread: 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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
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 directoryWhich 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