Re: disposition of remaining patches

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: disposition of remaining patches
Date: 2011-02-26 00:44:02
Message-ID: AANLkTinch936CcHyxee4wRz9TCHjZBjO2wXVbE3jmUg9@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 25, 2011 at 4:36 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> Daniel,
>
>> Ah, okay, I had missed that discussion, I also did not know it got so
>> specific as to address this case (are you sure?) rather than something
>> more general, say quorum or N-safe durability.
>
> The way we address that case is through n-safe durability.

How is this exposed? The simple "count the number of fsyncs()"
approach is not quite good enough (one has no control to make sure one
or more nodes are definitely up-to-date) unless one wants to just make
it go to *all* syncrep standys for a while. That seems like overkill;
so I imagine something else is in the thoughts. I'll search the
archives...

>> The user may have their own level of durability guarantee they want to
>> attain (that's why machine "B" is syncrepped in my example), but when
>> doing the switchover I think an override to enable a smooth handoff
>> (meaning: everything syncrepped) would be best.  What I want to avoid
>> is an ack from "COMMIT" from the primary (machine "A"), and then, post
>> switchover, the data isn't there on machine A-Prime (or "B", provided
>> it was able to follow successfully at all, as in the current case it
>> might get ahead of A-prime in the WAL).
>
> Yeah, when I think about your use case, I can understand why it's an
> issue.  It would be nice to have a superuser setting (or similar) which
> could override user preferances and make all transactions synchrep
> temporarily.  I'm not sure that's going to be reasonable to do for 9.1
> though.

Agreed; I'd be happy to take any syncrep functionality, although it
wouldn't compose well as-is, I wanted to raise this so that we didn't
make any configuration decisions that got in the way of making
composition possible later. Again, I haven't thought ahead yet,
partially because I thought there may be some existing thoughts in
play to consider.

With that, I will try to give syncrep a more structured review Real
Soon, although the late date of this is leaving me queasy as to the
odds of git-commit.

--
fdr

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2011-02-26 00:52:56 Re: Sync Rep v17
Previous Message Josh Berkus 2011-02-26 00:36:12 Re: disposition of remaining patches