Re: Some code cleanup for pgbench and pg_verifybackup
От | Robert Haas |
---|---|
Тема | Re: Some code cleanup for pgbench and pg_verifybackup |
Дата | |
Msg-id | CA+TgmoYERso6gAymR1XcxaJC8ZmNKY49QTPTuY2ceXNVTXmXhQ@mail.gmail.com обсуждение исходный текст |
Ответ на | 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 |
On Tue, Jul 27, 2021 at 11:18 PM Michael Paquier <michael@paquier.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
В списке pgsql-hackers по дате отправления: