Re: post-freeze damage control
David Steele <david@pgmasters.net>
From: David Steele <david@pgmasters.net>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>,
Tom Kincaid <tomjohnkincaid@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
"Andrey M. Borodin" <x4mmm@yandex-team.ru>,
Alvaro Herrera <alvherre@alvh.no-ip.org>,
Stefan Fercot <stefan.fercot@protonmail.com>,
Robert Haas <robertmhaas@gmail.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-04-12T23:03:28Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
revert: Transform OR clauses to ANY expression
- ff9f72c68f67 17.0 landed
-
Fix incorrect calculation in BlockRefTableEntryGetBlocks.
- 55a5ee30cd65 17.0 cited
On 4/12/24 22:12, Tomas Vondra wrote: > On 4/11/24 23:48, David Steele wrote: >> On 4/11/24 20:26, Tomas Vondra wrote: >> >>> FWIW that discussion also mentions stuff that I think the feature should >>> not do. In particular, I don't think the ambition was (or should be) to >>> make pg_basebackup into a stand-alone tool. I always saw pg_basebackup >>> more as an interface to "backup steps" correctly rather than a complete >>> backup solution that'd manage backup registry, retention, etc. >> >> Right -- this is exactly my issue. pg_basebackup was never easy to use >> as a backup solution and this feature makes it significantly more >> complicated. Complicated enough that it would be extremely difficult for >> most users to utilize in a meaningful way. > > Perhaps, I agree we could/should try to do better job to do backups, no > argument there. But I still don't quite see why introducing such > infrastructure to "manage backups" should be up to the patch adding > incremental backups. I see it as something to build on top of > pg_basebackup/pg_combinebackup, not into those tools. I'm not saying that managing backups needs to be part of pg_basebackup, but I am saying without that it is not a complete backup solution. Therefore introducing advanced features that the user then has to figure out how to manage puts a large burden on them. Implementing pg_combinebackup inefficiently out of the gate just makes their life harder. >> But they'll try because it is a new pg_basebackup feature and they'll >> assume it is there to be used. Maybe it would be a good idea to make it >> clear in the documentation that significant tooling will be required to >> make it work. > > Sure, I'm not against making it clearer pg_combinebackup is not a > complete backup solution, and documenting the existing restrictions. Let's do that then. I think it would make sense to add caveats to the pg_combinebackup docs including space requirements, being explicit about the format required (e.g. plain), and also possible mitigation with COW filesystems. Regards, -David