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

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: [v9.2] Add GUC sepgsql.client_label
Дата
Msg-id 4F2D13250200002500044DAA@gw.wicourts.gov
обсуждение исходный текст
Ответ на [v9.2] Add GUC sepgsql.client_label  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Ответы Re: [v9.2] Add GUC sepgsql.client_label  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: basic pgbench runs with various performance-related patches
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [v9.2] Add GUC sepgsql.client_label