Re: is sync rep stalled?
От | Aidan Van Dyk |
---|---|
Тема | Re: is sync rep stalled? |
Дата | |
Msg-id | AANLkTi=7Y86mnHrxhiJY_eq1N2WvQ22qAwGAf6s7P3Lt@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: is sync rep stalled? (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: is sync rep stalled?
|
Список | pgsql-hackers |
On Thu, Sep 30, 2010 at 2:09 AM, Heikki Linnakangas <heikki.linnakangas@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.
В списке pgsql-hackers по дате отправления: