From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: trivial improvement to system_or_bail |
Date: | 2021-07-06 21:59:11 |
Message-ID: | 202107062159.mnkybjgs2u23@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021-Jun-30, Daniel Gustafsson wrote:
> + BAIL_OUT("system $_[0] failed: $!\n");
> I wonder if we should take more inspiration from the Perl manual and change it
> to "failed to execute" to make it clear that the failure was in executing the
> program, not from the program itself?
You're right, that's a good distinction to make. I've used this
wording. Thanks.
> +1 for adding the extra details, but another thing that I've always found
> very confusing is just the phrasing of the message itself. It makes
> no sense unless (a) you know that "system" is Perl's function for
> executing a shell command, (b) you are familiar with Perl's generally
> cavalier approach to parentheses, and (c) you are also unbothered by
> whether the word "failed" is part of the message text or the command
> being complained of. We really need to do something to set off the
> shell command's text from the surrounding verbiage a little better.
>
> I'd prefer something like
>
> command "pg_ctl start" failed: details here
Done that way, thanks for the suggestion.
Failures now look like this, respectively:
Bailout called. Further testing stopped: failed to execute command "finitdb -D /home/alvherre/Code/pgsql-build/master/src/test/recovery/tmp_check/t_019_replslot_limit_primary_data/pgdata -A trust -N --wal-segsize=1": No such file or directory
Bailout called. Further testing stopped: command "initdb -0D /home/alvherre/Code/pgsql-build/master/src/test/recovery/tmp_check/t_019_replslot_limit_primary_data/pgdata -A trust -N --wal-segsize=1" exited with value 1
Bailout called. Further testing stopped: command "initdb -0D /home/alvherre/Code/pgsql-build/master/src/test/recovery/tmp_check/t_019_replslot_limit_primary_data/pgdata -A trust -N --wal-segsize=1" died with signal 11
Previously it was just
Bailout called. Further testing stopped: system initdb failed
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"I must say, I am absolutely impressed with what pgsql's implementation of
VALUES allows me to do. It's kind of ridiculous how much "work" goes away in
my code. Too bad I can't do this at work (Oracle 8/9)." (Tom Allison)
http://archives.postgresql.org/pgsql-general/2007-06/msg00016.php
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2021-07-06 22:12:31 | Re: visibility map corruption |
Previous Message | Peter Geoghegan | 2021-07-06 21:27:34 | Re: visibility map corruption |