On Fri, Jan 21, 2011 at 11:59 AM, Simon Riggs <si...@2ndquadrant.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. a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
