Обсуждение: BUG #5107: Lock never released

Поиск
Список
Период
Сортировка

BUG #5107: Lock never released

От
"Christian DUPONT"
Дата:
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.

Re: BUG #5107: Lock never released

От
Tom Lane
Дата:
"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

Re: BUG #5107: Lock never released

От
Chris Browne
Дата:
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