BUG #5107: Lock never released
The following bug has been logged online:
Bug reference: 5107
Logged by: Christian DUPONT
Email address: christian.dupont@cegelec.com
PostgreSQL version: 8.3
Operating system: RHEL 5
Description: Lock never released
Details:
Hi,
I use slony 1 v 1.2.14.
After an unexpected stop, several tables remained locked :
sl_log_1 -> RowExclusiveLock,
sl_log_status -> AccessShareLock,
sl_action_seq -> AccessShareLock,
h_jou_pmvdata -> RowExclusiveLock (data table).
This has happened a couple of times, even though I don't have a way to
reproduce it. A database restart does not help. Because of these locks, I
can't get rid (truncate / delete) of the tables nor even dump the db.
Only solution : destroy and rebuild from the master database (it is
replicated after all).
I would be glad to send any information needed to investigate.
"Christian DUPONT" <christian.dupont@cegelec.com> writes:
I use slony 1 v 1.2.14.
After an unexpected stop, several tables remained locked :
Is it possible that the locks are being held by a prepared transaction?
Next time it happens, look into the pg_prepared_xacts status view.
If it's not that, it seems like this must be a Slony issue, not a
problem with Postgres proper. You'll probably get better results
if you ask about it on the Slony mailing lists.
regards, tom lane
tgl@sss.pgh.pa.us (Tom Lane) writes:
"Christian DUPONT" <christian.dupont@cegelec.com> writes:
I use slony 1 v 1.2.14.
After an unexpected stop, several tables remained locked :Is it possible that the locks are being held by a prepared transaction?
Next time it happens, look into the pg_prepared_xacts status view.
The prepared statement idea seems pretty plausible; certainly it's
something that can survive a backend restart.
If it's not that, it seems like this must be a Slony issue, not a
problem with Postgres proper. You'll probably get better results
if you ask about it on the Slony mailing lists.
I can't think of anything offhand which would seize a lock so
tenaciously in Slony, except, evidently with a prepared statement as
an accomplice.
--
select 'cbbrowne' || '@' || 'gmail.com';
http://linuxdatabases.info/info/emacs.html
"I really only meant to point out how nice InterOp was for someone who
doesn't have the weight of the Pentagon behind him. I really don't
imagine that the Air Force will ever be able to operate like a small,
competitive enterprise like GM or IBM." -- Kent England