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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17122: panic on prepare with subsequent pg_advisory_lock() and pg_advisory_xact_lock_shared()
Дата
Msg-id 924498.1627056766@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #17122: panic on prepare with subsequent pg_advisory_lock() and pg_advisory_xact_lock_shared()  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: BUG #17122: panic on prepare with subsequent pg_advisory_lock() and pg_advisory_xact_lock_shared()  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
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



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Pawel Kudzia
Дата:
Сообщение: Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows
Следующее
От: Andrey Borodin
Дата:
Сообщение: Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data