| Lists: | pgsql-general |
|---|
| From: | Stephen Rees <srees(at)pandora(dot)com> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Advisory Locks and Prepared Transactions |
| Date: | 2012-04-17 02:38:07 |
| Message-ID: | E44E91D5-3817-41DE-B174-0005D31E20AE@pandora.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-general |
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
| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Rees <srees(at)pandora(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Advisory Locks and Prepared Transactions |
| Date: | 2012-05-03 00:13:12 |
| Message-ID: | 7422.1336003992@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-general |
[ sorry for slow response ]
Stephen Rees <srees(at)pandora(dot)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