Re: Avoiding inadvertent debugging mode for pgbench

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoiding inadvertent debugging mode for pgbench
Date: 2024-03-01 23:07:49
Message-ID: 24d757e3-1641-48b8-b8c1-2a71e5a05328@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/1/24 23:41, Nathan Bossart wrote:
> On Thu, Feb 29, 2024 at 07:05:13PM -0500, Greg Sabino Mullane wrote:
>> Attached please find a patch to adjust the behavior of the pgbench program
>> and make it behave like the other programs that connect to a database
>> (namely, psql and pg_dump). Specifically, add support for using -d and
>> --dbname to specify the name of the database. This means that -d can no
>> longer be used to turn on debugging mode, and the long option --debug must
>> be used instead.
>>
>> This removes a long-standing footgun, in which people assume that the -d
>> option behaves the same as other programs. Indeed, because it takes no
>> arguments, and because the first non-option argument is the database name,
>> it still appears to work. However, people then wonder why pgbench is so
>> darn verbose all the time! :)
>>
>> This is a breaking change, but fixing it this way seems to have the least
>> total impact, as the number of people using the debug mode of pgbench is
>> likely quite small. Further, those already using the long option are
>> unaffected, and those using the short one simply need to replace '-d' with
>> '--debug', arguably making their scripts a little more self-documenting in
>> the process.
>
> I think this is a generally reasonable proposal, except I don't know
> whether this breakage is acceptable. AFAICT there are two fundamental
> behavior changes folks would observe:
>
> * "-d <database_name>" would cease to emit the debugging output, and while
> enabling debug mode might've been unintentional in most cases, it might
> actually have been intentional in others.
>

I think this is the more severe of the two issues, because it's a silent
change. Everything will seem to work, but the user won't get the debug
info (if they actually wanted it).

> * "-d" with no argument or with a following option would begin failing, and
> users would need to replace "-d" with "--debug".
>

I think this is fine.

> Neither of these seems particularly severe to me, especially for a
> benchmarking program, but I'd be curious to hear what others think.
>

I agree the -d option may be confusing, but is it worth it? I don't
know, it depends on how often people actually get confused by it, and I
don't recall hitting this (nor hearing about others). To be honest I
didn't even realize pgbench even has a debug switch ...

But I'd like to mention this is far from our only tool using "-d" to
enable debug mode. A quick git-grep shows postgres, initdb,
pg_archivecleanup and pg_combinebackup do the same thing. So maybe it's
not that inconsistent overall.

(Note: I didn't check if the other cases may lead to the same confusion
where people enable debug accidentally. Maybe not.)

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2024-03-02 00:11:26 Re: Showing applied extended statistics in explain Part 2
Previous Message Melanie Plageman 2024-03-01 22:44:38 Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE