[SQL] transaction isolationa level - SERIALIZABLE

2013-05-13 Thread Marcin Krawczyk
Hi list,

I have some problems with SERIALIZABLE isolation level, namely my users are
plagued with concurrency errors. As of postgres 9.1 (which I'm running)
there has been a change to SERIALIZABLE logic, unfortunately my application
has not been updated to work with the new logic. I don't have an access to
it's code and the only thing I can do is to report the issue to the
authors. But before I do it, since I don't actually need SERIALIZABLE for
my use, is it possible to have transactions always run in default READ
COMMITTED mode, regardless of application level SET SESSION CHARACTERISTICS
AS TRANSACTION command ... ? (like e.g in postgres 8.1 where SERIALIZABLE =
READ COMMITED)


regards
mk


Re: [SQL] transaction isolationa level - SERIALIZABLE

2013-05-13 Thread Adrian Klaver

On 05/13/2013 02:22 AM, Marcin Krawczyk wrote:

Hi list,

I have some problems with SERIALIZABLE isolation level, namely my users
are plagued with concurrency errors. As of postgres 9.1 (which I'm
running) there has been a change to SERIALIZABLE logic, unfortunately my
application has not been updated to work with the new logic. I don't
have an access to it's code and the only thing I can do is to report the
issue to the authors. But before I do it, since I don't actually
need SERIALIZABLE for my use, is it possible to have transactions always
run in default READ COMMITTED mode, regardless of application level SET
SESSION CHARACTERISTICS AS TRANSACTION command ... ? (like e.g in
postgres 8.1 where SERIALIZABLE = READ COMMITED)


I don't think so:

http://www.postgresql.org/docs/9.1/interactive/config-setting.html

Furthermore, it is possible to assign a set of parameter settings to a 
user or a database. Whenever a session is started, the default settings 
for the user and database involved are loaded. The commands ALTER ROLE 
and ALTER DATABASE, respectively, are used to configure these settings. 
Per-database settings override anything received from the postgres 
command-line or the configuration file, and in turn are overridden by 
per-user settings; both are overridden by per-session settings.





regards
mk



--
Adrian Klaver
adrian.kla...@gmail.com


--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql


Re: [SQL] transaction isolationa level - SERIALIZABLE

2013-05-13 Thread Marcin Krawczyk
That's what I thought. Thank you.


regards
mk


2013/5/13 Adrian Klaver adrian.kla...@gmail.com

 On 05/13/2013 02:22 AM, Marcin Krawczyk wrote:

 Hi list,

 I have some problems with SERIALIZABLE isolation level, namely my users
 are plagued with concurrency errors. As of postgres 9.1 (which I'm
 running) there has been a change to SERIALIZABLE logic, unfortunately my
 application has not been updated to work with the new logic. I don't
 have an access to it's code and the only thing I can do is to report the
 issue to the authors. But before I do it, since I don't actually
 need SERIALIZABLE for my use, is it possible to have transactions always
 run in default READ COMMITTED mode, regardless of application level SET
 SESSION CHARACTERISTICS AS TRANSACTION command ... ? (like e.g in
 postgres 8.1 where SERIALIZABLE = READ COMMITED)


 I don't think so:

 http://www.postgresql.org/**docs/9.1/interactive/config-**setting.htmlhttp://www.postgresql.org/docs/9.1/interactive/config-setting.html

 Furthermore, it is possible to assign a set of parameter settings to a
 user or a database. Whenever a session is started, the default settings for
 the user and database involved are loaded. The commands ALTER ROLE and
 ALTER DATABASE, respectively, are used to configure these settings.
 Per-database settings override anything received from the postgres
 command-line or the configuration file, and in turn are overridden by
 per-user settings; both are overridden by per-session settings.



 regards
 mk



 --
 Adrian Klaver
 adrian.kla...@gmail.com