Re: BUG #17122: panic on prepare with subsequent pg_advisory_lock() and pg_advisory_xact_lock_shared()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: a(dot)pyhalov(at)postgrespro(dot)ru
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17122: panic on prepare with subsequent pg_advisory_lock() and pg_advisory_xact_lock_shared()
Date: 2021-07-23 16:12:46
Message-ID: 924498.1627056766@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrey Borodin 2021-07-23 16:33:18 Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Previous Message Pawel Kudzia 2021-07-23 15:04:50 Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows