Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 862FD1337B4A for ; Fri, 21 Jan 2011 14:03:48 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 37890-08 for ; Fri, 21 Jan 2011 18:03:41 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id E66F11337B51 for ; Fri, 21 Jan 2011 14:03:40 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id p0LI3MPE014762; Fri, 21 Jan 2011 13:03:23 -0500 (EST) To: Robert Haas cc: Aidan Van Dyk , Simon Riggs , Heikki Linnakangas , pgsql-hackers@postgresql.org Subject: Re: Sync Rep for 2011CF1 In-reply-to: References: <1295127631.3282.100.camel@ebony> <4D397FE4.2020709@enterprisedb.com> <1295616270.1803.10799.camel@ebony> <4D39A761.1020105@enterprisedb.com> <1295629194.1803.11957.camel@ebony> Comments: In-reply-to Robert Haas message dated "Fri, 21 Jan 2011 12:30:04 -0500" Date: Fri, 21 Jan 2011 13:03:22 -0500 Message-ID: <14761.1295633002@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201101/2135 X-Sequence-Number: 179972 Robert Haas writes: > On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk 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.) regards, tom lane