From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Some code cleanup for pgbench and pg_verifybackup |
Date: | 2021-07-28 03:18:12 |
Message-ID: | YQDMdB+B68yePFeT@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 27, 2021 at 08:53:52AM +0900, Michael Paquier wrote:
> On Mon, Jul 26, 2021 at 03:35:29PM -0400, Alvaro Herrera wrote:
>> (In reality we cannot literally just exit(1) in pg_log_fatal(), because
>> there are quite a few places that do some other thing after the log
>> call and before exit(1), or terminate the program in some other way than
>> exit().)
>
> Yes, that's obviously wrong. I am wondering if there is more of
> that.
I have been looking at that. Here are some findings:
- In pg_archivecleanup, CleanupPriorWALFiles() does not bother
exit()'ing with an error code. Shouldn't we worry about reporting
that correctly? It seems strange to not inform users about paths that
would be broken, as that could bloat the archives without one knowing
about it.
- In pg_basebackup.c, ReceiveTarAndUnpackCopyChunk() would not
exit() when failing to change permissions for non-WIN32.
- pg_recvlogical is missing a failure handling for fstat(), as of
5c0de38.
- pg_verifybackup is in the wrong, as mentioned upthread.
Thoughts? All that does not seem to enter into the category of things
worth back-patching, except for pg_verifybackup.
--
Michael
Attachment | Content-Type | Size |
---|---|---|
log-fatal-exit.patch | text/x-diff | 3.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Nancarrow | 2021-07-28 03:20:47 | Re: [bug?] Missed parallel safety checks, and wrong parallel safety |
Previous Message | David Rowley | 2021-07-28 03:04:31 | Re: ATTACH PARTITION locking documentation for DEFAULT partitions |