Re: Sync Rep for 2011CF1

On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
> On Fri, Jan 21, 2011 at 11:59 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
>> We all think our own proposed options are the only reasonable thing, but
>> that helps us not at all in moving forwards. I've put much time into
>> delivering options many other people want, so there is a range of
>> function. I think we should hear from Aidan first before we decide to
>> remove that aspect.
>
> Since invited, I'll describe what I *want* do to do.  I understand I
> may not get it ;-)
>
> When no sync slave is connected, yes, I want to stop things hard.  I
> don't mind read-only queries working, but what I want to avoid (if
> possible) is having the master do lots of inserts/updates/deletes for
> clients, fsyncing them all to disk (so on some strange event causing
> recovery they'll be considered commit) and just delay the commit
> return until it has a valid sync slave connected and caught up again.
> And *I*'ld prefer if client transactions get errors right away rather
> than begin to hang if a sync slave is not connected.
>
> Even with single server, there's the window where stuff could be
> "committed" but the client not notified yet.  And that leads to
> transactions which need to be verified.  And with sync rep, that
> window get's a little larger.  But I'ld prefer not to make it a hanger
> door, *especially* when it gets flung open at the point where the shit
> has hit the fan and we're in the midst of switching over to manual
> processing...
>
> So, in my case, I'ld like it if PG couldn't do anything to generate
> any user-initiated WAL unless there is a sync slave connected.  Yes, I
> understand that leads to hard-fail, and yes, I understand I'm in the
> minority, maybe almost singular in that desire.

What you're proposing is to fail things earlier than absolutely
necessary (when they try to XLOG, rather than at commit) but still
later than what I think Simon is proposing (not even letting them log
in).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company