Re: trivial improvement to system_or_bail

Started by Alvaro Herreraalmost 5 years ago2 messageshackers
Jump to latest
#1Alvaro Herrera
alvherre@2ndquadrant.com

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

#2Daniel Gustafsson
daniel@yesql.se
In reply to: Alvaro Herrera (#1)

On 6 Jul 2021, at 23:59, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

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

That is no doubt going to be helpful, thanks!

--
Daniel Gustafsson https://vmware.com/