Thread: Advisory Locks and Prepared Transactions
Code that works on Pg8.3 raises an error on Pg9.1, is this a bug?
PostgreSQL 8.3.7 on x86_64-unknown-linux-gnu, compiled by GCC gcc-4.3.real (Debian 4.3.2-1.1) 4.3.2
select pg_try_advisory_lock(123);
pg_try_advisory_lock
----------------------
t
(1 row)
postgres=# begin transaction;
BEGIN
postgres=# prepare transaction 'tran1';
PREPARE TRANSACTION
postgres=# commit prepared 'tran1';
COMMIT PREPARED
PostgreSQL 9.1.2 on x86_64-unknown-linux-gnu, compiled by gcc-4.3.real (Debian 4.3.2-1.1) 4.3.2, 64-bit
select pg_try_advisory_lock(123);
pg_try_advisory_lock
----------------------
t
(1 row)
postgres=# begin transaction;
BEGIN
postgres=# prepare transaction 'tran1';
ERROR: cannot PREPARE when session locks exist
- Steve
[ sorry for slow response ] Stephen Rees <srees@pandora.com> writes: > Code that works on Pg8.3 raises an error on Pg9.1, is this a bug? Yes, it sure looks that way. Somebody decided they could mark userlocks as transactional, which was probably a bad idea altogether, and certainly wasn't followed up on adequately. regards, tom lane