On Fri, Jan 21, 2011 at 1:03 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk <ai...@highrise.ca> wrote: >>> When no sync slave is connected, yes, I want to stop things hard. > >> 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). > > I can't see a reason to disallow login, because read-only transactions > can still run in such a situation --- and, indeed, might be fairly > essential if you need to inspect the database state on the way to fixing > the replication problem. (Of course, we've already had the discussion > about it being a terrible idea to configure replication from inside the > database, but that doesn't mean there might not be views or status you > would wish to look at.)
And just disallowing new logins is probably not even enough, because it allows current logged in clients "forward progress", leading towards an eventual hang (with now committed data on the master). Again, I'm trying to stop "forward progress" as soon as possible when a sync slave isn't replicating. And I'ld like clients to fail with errors sooner (hopefully they get to the commit point) rather than accumulate the WAL synced to the master and just wait at the commit. So I think that's a more complete picture of my quick "not do anything with no synchronous slave replicating" that I think was what led to the no-login approach. 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
