Re: trivial improvement to system_or_bail

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

In response to

Responses

Browse pgsql-hackers by date

  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