Re: Proof of concept: standalone backend with full FE/BE protocol
Josh Berkus <josh@agliodbs.com>
From: Josh Berkus <josh@agliodbs.com>
To: pgsql-hackers@postgresql.org
Date: 2012-09-05T22:30:53Z
Lists: pgsql-hackers
> Um ... true with respect to autovacuum, perhaps, but what about > checkpoints? A standalone backend will never perform a checkpoint > unless explicitly told to. Hmmm, that's definitely an issue. > (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. Yeah, we'd have to put in a clock-based thing which did checkpoints every 5 minutes and VACUUM ANALYZE every hour or something. That seems like a chunk of extra code. > 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. Well, don't discount the development/testing case. If you do agile or TDD (a lot of people do), you often have a workload which looks like: 1) Start framework 2) Start database 3) Load database with test data 4) Run tests 5) Print results 6) Shut down database In a case like that, you can live without checkpointing, even; the database is ephemeral. In other words, let's make this a feature and document it for use in testing, and that it's not really usable for production embedded apps yet. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove now redundant pgpipe code.
- d2c1740dc275 9.2.0 cited