Re: Avoiding inadvertent debugging mode for pgbench
От | Tomas Vondra |
---|---|
Тема | Re: Avoiding inadvertent debugging mode for pgbench |
Дата | |
Msg-id | 24d757e3-1641-48b8-b8c1-2a71e5a05328@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Avoiding inadvertent debugging mode for pgbench (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: Avoiding inadvertent debugging mode for pgbench
("Euler Taveira" <euler@eulerto.com>)
|
Список | 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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Melanie PlagemanДата:
Сообщение: Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE
Следующее
От: Tomas VondraДата:
Сообщение: Re: Showing applied extended statistics in explain Part 2