> Well I guess I'd prefer a per-transaction setting, allowing to bypass
> WAL logging and checkpointing.
Not even conceiveable. For this to work, we're talking about the whole
database installation. This is only a set of settings for a database
*server* which is considered disposable and replaceable, where if it
shuts down unexpectedly, you throw it away and replace it.
> Forcing the backend to care itself for
> writing the data I'm not sure is a good thing, but if you say so.
Oh, yeah, I guess we'd only be turning off the LRU cache operations of
the background writer. Same with checkpoints. Copying between
shared_buffers and the LRU cache would still happen.
> Calling a user function at the end of recovery and before accepting
> connection would be good I think. A user function (per database) is
> better than a script because if you want to run it before accepting
> connections and still cause changes in the database…
Hmmm, you're not quite following my idea. There is no recovery. If the
database shuts down unexpectedly, it's toast and you replace it from
another copy somewhere else.
> (a) and (d) are probably simple, if by "reprovisioning" you mean
> "rm -rf $PGDATA; initdb".
Exactly. Followed by "scp database_image". Or heck, just replacing the
whole VM.
> Point (b) will be a bit trickier because
> there are various housekeeping activities tied into checkpoints.
> I think you can't actually remove checkpoints altogether, just
> skip the flush-dirty-pages part.
Yes, and we'd want to flush dirty pages on an actual shutdown command.
We do want to be able to shut down the DB on purpose.
> Well if the transaction touches a system catalog it better be
> WAL-logged...
Given the above, why?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com