Re: Some code cleanup for pgbench and pg_verifybackup
От | Fabien COELHO |
---|---|
Тема | Re: Some code cleanup for pgbench and pg_verifybackup |
Дата | |
Msg-id | alpine.DEB.2.22.394.2107271136000.297424@pseudo обсуждение исходный текст |
Ответ на | Re: Some code cleanup for pgbench and pg_verifybackup (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Some code cleanup for pgbench and pg_verifybackup
|
Список | pgsql-hackers |
Hello, >> I do not understand your disagreement. Do you disagree about the >> expected>> semantics of fatal? Then why provide fatal if it should not >> be used? What is the expected usage of fatal? > > I disagree about the fact that pgbench uses pg_log_fatal() in ways > that other binaries don't do. Sure. Then what should be the expected usage of fatal? Doc says: * Severe errors that cause program termination. (One-shot programs may * chose to label even fatal errors as merely "errors". The distinction * is up to the program.) pgbench is consistent with the doc. I prefer fatal for this purpose to distinguish these clearly from recoverable errors, i.e. the programs goes on despite the error, or at least for some time. I think it is good to have such a distinction, and bgpench has many errors and many fatals, although maybe some error should be fatal and some fatal should be error… > For example, other things use pg_log_error() followed by an exit(), but > not this code. Sure. > I am not going to fight hard on that, though. Me neither. > That's a set of inconsistences I bumped into while plugging in > option_parse_int() Which is a very good thing! I have already been bitten by atoi. -- Fabien.
В списке pgsql-hackers по дате отправления: