Skip site navigation (1) Skip section navigation (2)

Re: [v9.2] Add GUC sepgsql.client_label

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <robertmhaas(at)gmail(dot)com>,<tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <yebhavinga(at)gmail(dot)com>,<kaigai(at)kaigai(dot)gr(dot)jp>, <pgsql-hackers(at)postgresql(dot)org>, <jbrindle(at)tresys(dot)com>
Subject: Re: [v9.2] Add GUC sepgsql.client_label
Date: 2012-02-04 17:14:45
Message-ID: 4F2D13250200002500044DAA@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane  wrote:
 
> More to the point, a GUC rollback transition *has to always
> succeed*.  Period.
 
I was about to point out the exception of the transaction_read_only
GUC, which according to the standard must not be changed except at
the beginning of a transaction or a subtransaction, and must not be
changed from "on" to "off" in a subtransaction.  Then I noticed that,
while we protect against an explicit change in a prohibited way, we
allow a RESET:
 
test=# begin transaction read only;
BEGIN
test=# select * from x;
 x 
---
 1
(1 row)

test=# set transaction_read_only = off;
ERROR:  transaction read-write mode must be set before any query
test=# rollback;
ROLLBACK
test=# begin transaction read only;
BEGIN
test=# select * from x;
 x 
---
 1
(1 row)

test=# reset transaction_read_only ;
RESET
test=# insert into x VALUES (2);
INSERT 0 1
test=# commit;
COMMIT
 
I think that's a problem.  It could allow back-door violations of
invariants enforced by triggers, and seems to violate the SQL
standard.  I think this should be considered a bug, although I'm not
sure whether it's safe to back-patch, given the change to existing
behavior.
 
Whether such a (required) exception to what you assert above should
open the door to any others is another question.
 
-Kevin

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-02-04 17:54:38
Subject: Re: [v9.2] Add GUC sepgsql.client_label
Previous:From: Greg SmithDate: 2012-02-04 16:59:42
Subject: Re: basic pgbench runs with various performance-related patches

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group