Re: Proof of concept: standalone backend with full FE/BE protocol

Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> However, there are some additional things
>> we'd need to think about before advertising it as a fit solution for that.
>> Notably, while the lack of any background processes is just what you want
>> for pg_upgrade and disaster recovery, an ordinary application is probably
>> going to want to rely on autovacuum; and we need bgwriter and other
>> background processes for best performance. So I'm speculating about
>> having a postmaster process that isn't listening on any ports, but is
>> managing background processes in addition to a single child backend.
>> That's for another day though.

> Well, if you think about standalone mode as "developer" mode, it's not
> quite so clear that we'd need those things. Generally when people are
> testing code in development they don't care about vacuum or bgwriter
> because the database is small and ephemeral. So even without background
> processes, standalone mode would be useful for many users for
> development and automated testing.

Only if startup and shutdown were near instantaneous, which as Andres
was pointing out would be far from the truth. I am envisioning the
use-case for this thing as stuff like desktop managers and mail
programs, which tend to be rather lumbering on startup anyway. (And
yes, a lot of those have got embedded databases in them these days.
More often than not it's mysql.) I don't see people wanting to use this
feature for unit tests.

> For that matter, applications which embed postgresql and have very small
> databases could also live without autovacuum and bgwriter. Heck,
> Postgres existed without them for many years.

Um ... true with respect to autovacuum, perhaps, but what about
checkpoints? A standalone backend will never perform a checkpoint
unless explicitly told to. (Before we invented the bgwriter, the
postmaster was in charge of launching checkpoints every so often.)
Again, this is probably just what you want for disaster recovery, but
it wouldn't be terribly friendly for an embedded-database application.

In general I think the selling point for such a feature would be "no
administrative hassles", and I believe that has to go not only for the
end-user experience but also for the application-developer experience.
If you have to manage checkpointing and vacuuming in the application,
you're probably soon going to look for another database.

regards, tom lane