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()
|
Список | 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 по дате отправления: