PG Bug reporting form <noreply@postgresql.org> writes:
> The following statements lead to panic:
> begin;
> select pg_advisory_lock(1);
> select pg_advisory_xact_lock_shared(1);
> prepare transaction 'test';
Thanks for the report! Looks like the shared lock is sufficient
to cause the problem:
regression=# begin;
BEGIN
regression=*# select pg_advisory_xact_lock_shared(1);
pg_advisory_xact_lock_shared
------------------------------
(1 row)
regression=*# prepare transaction 'test';
PANIC: we seem to have dropped a bit somewhere
server closed the connection unexpectedly
Taking only the other lock works fine. Even more interesting,
"select pg_advisory_xact_lock(1);" also works, as does
"select pg_advisory_lock_shared(1);". So it's specific to
xact-level shared locks, which seems downright weird.
I also tried this:
regression=# begin;
BEGIN
regression=*# select pg_advisory_lock_shared(1);
pg_advisory_lock_shared
-------------------------
(1 row)
regression=*# select pg_advisory_xact_lock(1);
pg_advisory_xact_lock
-----------------------
(1 row)
regression=*# select pg_advisory_lock(1);
pg_advisory_lock
------------------
(1 row)
regression=*# prepare transaction 'test';
ERROR: cannot PREPARE while holding both session-level and transaction-level locks on the same object
which makes me wonder why we didn't issue that error in your
example case. However, that's not sufficient to explain
the crash with only the xact-shared lock.
BTW, note that we do manage to prepare the transaction before
crashing, so you must do
commit prepared 'test';
to clean up before trying again.
regards, tom lane
