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

Re: 'SET LOCAL ROLE blah;' doesn't work?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 'SET LOCAL ROLE blah;' doesn't work?
Date: 2007-09-09 15:54:35
Message-ID: 24895.1189353275@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
[ see thread at
http://archives.postgresql.org/pgsql-bugs/2007-06/msg00166.php ]

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Alvaro Herrera (alvherre(at)commandprompt(dot)com) wrote:
>> Tom Lane wrote:
>>> So actually, ON_ERROR_ROLLBACK breaks *any* use of SET LOCAL, not just
>>> ROLE.  Not sure that this is fixable :-(
>>
>> Maybe if psql sees "SET LOCAL" it shouldn't send the RELEASE command.
>> But it seems a bit error prone to be finding each command that may be
>> affected by RELEASE ... what other thing do we have that works at the
>> level of subtransactions?

> At the very least, anything which does work at the subtransaction level
> and not the transaction level should be documented as such...  I don't
> see anything (perhaps I've missed it) in the 'set local' or the 'release
> savepoint' documentation which describes this behavior... :/

I came across this open issue by chance while looking through my mail
folder, and realized that the recently proposed change to SET LOCAL's
behavior would resolve Stephen's complaint.  I believe that the end
result of the discussion in this thread:
http://archives.postgresql.org/pgsql-hackers/2007-09/msg00030.php
was that we should make SET LOCAL's effects persist until the end of
the current top transaction, unless reverted by subtransaction rollback
or the save/restore action of a function-local SET option for the same
GUC variable.  With that change, psql's automatic RELEASEs for
ON_ERROR_ROLLBACK mode won't affect the state of GUC variables.

So this reinforces my feeling that we came to the right conclusion
in last week's thread.  I haven't done anything about revising
the GUC code for that, but will get on it now.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-09-09 15:56:27
Subject: Re: invalidly encoded strings
Previous:From: Marko KreenDate: 2007-09-09 15:52:37
Subject: Re: pgcrypto related backend crash on solaris 10/x86_64

pgsql-bugs by date

Next:From: Dave PageDate: 2007-09-10 07:38:34
Subject: Re: BUG #3605: impossible loading
Previous:From: Jaime CasanovaDate: 2007-09-09 13:18:09
Subject: Re: HELP URGENTE

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