Hi,
On 2021-05-07 12:03:36 +0200, Magnus Hagander wrote:
> It might be interesting for us as developers, but not to the vast
> majority of our users. Most of those get their startup scripts from
> our packagers -- so maybe we should encourage packagers to provide it,
> like they do for PostgreSQL itself.
I think that's the entirely wrong direction to go. A lot of the
usability problems around postgres precisely stem from us doing this
kind of thing, where the user experience then ends up wildly varying,
incomplete and incomprehensible.
That's not to say that we need to reimplement everything just for a
consistent experience. But just punting crucial things like how a
archiving can be made reliable in face of normal-ish errors, and how it
can be monitored is just going to further force people to move purely
onto managed services.
> Or maybe the better solution in that case would perhaps be to actually
> bless one of the existing solutions out there by making it the
> official one.
Which existing system currently does provide an archiving solution that
does not imply the very significant overhead of archive_command? Even if
an archiving solution internally batches things, the fsyncs, filesystem
metadata operations for .ready .done are a *significant* cost and all
the forks are not cheap either.
Greetings,
Andres Freund