On Thu, Sep 30, 2010 at 2:09 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote:
> Agreed. Actually, given the lack of people jumping in and telling us what > they'd like to do with the feature, maybe it's not that important after all. >> The basic features that I mean is for most basic use case, that is, one >> master and one synchronous standby case. In detail, > > ISTM the problem is exactly that there is no consensus on what the basic use > case is. I'm sure there's several things you can accomplish with synchronous > replication, perhaps you could describe what the important use case for you > is? OK, So I'll throw in my ideal use case. I'm starting to play with Magnus's "streaming -> archive". *that's* what I want, with synchronous. Yes, again, I'm looking for "data durability", not "server query-ability", and I'ld like to rely on the PG user-space side of things instead of praying that replicated block-devices hold together.... If my master flips out, I'm quite happy to do a normal archive restore. Except I don't want that last 16MB (or archive timeout) of transactions lost. The streaming -> archive in it's current state get's me pretty close, but I'ld love to be able to guarantee that my recovery from that archive has *every* transaction that the master committed... a. a. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
