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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Date: 2012-09-05 21:09:41
Message-ID: 20120905210941.GF8774@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-09-05 21:28:45 Re: Cascading replication on Windows bug
Previous Message Heikki Linnakangas 2012-09-05 21:03:55 Cascading replication on Windows bug