Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btlEg-0007Ru-NS for pgsql-docs@arkaria.postgresql.org; Tue, 11 Oct 2016 00:48:02 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1btlEg-0000kW-AD for pgsql-docs@arkaria.postgresql.org; Tue, 11 Oct 2016 00:48:02 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1btlEI-0007Uk-BT for pgsql-docs@postgresql.org; Tue, 11 Oct 2016 00:47:38 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1btlEF-0002Ro-EG for pgsql-docs@postgresql.org; Tue, 11 Oct 2016 00:47:37 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B7A27208AB; Mon, 10 Oct 2016 20:47:34 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 10 Oct 2016 20:47:34 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=gAnYnW+oxqWx90s LLdOvgOVdZ+8=; b=gn2Zruw7FJebU57vZsyCI2/lQVhSv6NOfYl2g+Ix4E3mIpF 7n4bVoNvD1yrQ+/wNQpLYmyaKQpq4fJc4wlZXW3rAcxXghf7FMH2/rjz29ets3ed 6CeldTvb+zp+G7SfNU+gid96Z6VaRad457E71ojUv1iw+2d7mpqRJnO36bT0= X-Sasl-enc: SVvFuMAxD6Lu+7I0ogfld4A1DC2iEq+uOs16s9pv4USS 1476146854 Received: from april.local (c-73-13-66-39.hsd1.pa.comcast.net [73.13.66.39]) by mail.messagingengine.com (Postfix) with ESMTPA id 5D393F29CE; Mon, 10 Oct 2016 20:47:34 -0400 (EDT) Subject: Re: SET CONSTRAINTS ALL IMMEDIATE affects SET TRANSACTION READ ONLY To: Tom Lane , chris+postgresql@qwirx.com References: <20160909065218.20022.15589@wrigleys.postgresql.org> <5491.1473439146@sss.pgh.pa.us> Cc: pgsql-docs@postgresql.org From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: Date: Mon, 10 Oct 2016 20:47:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5491.1473439146@sss.pgh.pa.us> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org On 9/9/16 12:39 PM, Tom Lane wrote: > chris+postgresql@qwirx.com writes: >> We found that normally, if you execute SET TRANSACTION READ ONLY, it >> prevents COMMIT from happening if any data has been changed in the >> transaction (and we have been relying on this for safety). > > This seems like a truly bizarre expectation. > > I wouldn't really imagine that it's sensible to set READ ONLY > mid-transaction at all, but if it means anything to do that, surely > it ought to mean that no updates can happen *after* you set it. I think there is a bit of code missing in check_transaction_read_only(). We prevent changing from read-only to read-write after the first query but not vice versa. That seems like an oversight. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs