From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Sync Rep for 2011CF1 |
Date: | 2011-01-21 15:53:11 |
Message-ID: | AANLkTi=SLjJUCWcj=2EUShOsv1+pGVZF-0_gQuvHJgev@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 21, 2011 at 10:33 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> It's also possible that most of your transactions in fact do "set
> synchronous_replication=off", and only a few actually do synchronous
> replication. It would be pretty bad to not allow connections in that case.
> And what if you want to connect to the server to diagnose the issue? Oh, you
> can't... Besides, we're not kicking out existing connections, are we? Seems
> inconsistent to let the old connections live.
>
> IMHO the only reasonable option is to allow connections as usual, and only
> fail (or block forever) at COMMIT.
Another point is that the synchronous standby could come back at any
time. There's no reason not to let the client do all the work they
want up until the commit - maybe the standby will pop back up before
the COMMIT actually issued. Or even if it doesn't, as soon as it pops
back up, all those COMMITs get released.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-21 15:54:09 | Re: More detailed auth info |
Previous Message | Robert Haas | 2011-01-21 15:50:42 | Re: sepgsql contrib module |