From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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 14:28:13 |
Message-ID: | CA+TgmoYERso6gAymR1XcxaJC8ZmNKY49QTPTuY2ceXNVTXmXhQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 27, 2021 at 11:18 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> 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.
I think all of these are reasonable fixes. In the case of
pg_basebackup, a chmod() failure doesn't necessarily oblige us to give
up and exit; we could presumably still write the data. But it may be
best to give up and exit. The other cases appear to be clear bugs.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Gilles Darold | 2021-07-28 14:29:34 | Re: Case expression pushdown |
Previous Message | John W Higgins | 2021-07-28 14:23:50 | Re: Have I found an interval arithmetic bug? |