From: | Antonin Houska <ah(at)cybertec(dot)at> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_log_fatal vs pg_log_error |
Date: | 2019-06-17 13:39:49 |
Message-ID: | 3980.1560778789@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Mon, Jun 17, 2019 at 02:19:30PM +0200, Antonin Houska wrote:
> > I'd expect that the pg_log_fatal() should be called when the error is serious
> > enough to cause premature exit, but I can see cases where even pg_log_error()
> > is followed by exit(1). pg_waldump makes me feel that pg_log_error() is used
> > to handle incorrect user input (before the actual execution started) while
> > pg_log_fatal() handles error conditions that user does not fully control
> > (things that happen during the actual execution). But this is rather a guess.
>
> I agree with what you say when pg_log_fatal should be used for an
> error bad enough that the binary should exit immediately. In the case
> of pg_waldump, not using pg_log_fatal() makes the code more readable
> because there is no need to repeat the "Try --help for more
> information on a bad argument".
I'd understand this if pg_log_fatal() called exit() itself, but it does not
(unless I miss something).
> Have you spotted other areas of the code where it makes sense to change a
> pg_log_error() + exit to a single pg_log_fatal()?
I haven't done an exhaustive search so far, but as I mentioned above,
pg_log_fatal() does not seem to be "pg_log_error() + exit()".
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-06-17 13:44:46 | Re: pg_log_fatal vs pg_log_error |
Previous Message | Antonin Houska | 2019-06-17 13:25:12 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |