On Wed, Sep 5, 2012 at 01:50:06PM -0700, Josh Berkus wrote:
> Tom,
>
> > 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.
>
> 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.
>
> You just doc that, if you're running postgres standalone, you need to
> run a full VACUUM ANALYZE on the database cluster once per day. And you
> live with the herky-jerky write performance. If the database is 5GB,
> who's going to notice anyway?
If this mode slows down pg_upgrade, that is going to be a problem.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
