Re: Is Pg 7.0.x's Locking Mechanism BROKEN? - Mailing list pgsql-hackers

From frank
Subject Re: Is Pg 7.0.x's Locking Mechanism BROKEN?
Date
Msg-id 3980EBA3.B5B4685A@ieee.org
Whole thread Raw
In response to Re: Re: [GENERAL] Is Pg 7.0.x's Locking Mechanism BROKEN?  (JanWieck@t-online.de (Jan Wieck))
Responses Re: Is Pg 7.0.x's Locking Mechanism BROKEN?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Jan Wieck wrote:

> frank wrote:
> > Thanks Fabrice, that will help a lot.
> >
> > In my applications the conflict was not a direct table conflict e.g.
> > USER1 locks Table1 record that references Table2 via foreign key with a
> > cascade update/delete enforced then
> > USER2 tried to lock Table2 for update on the referenced record - result both
> > users locked !
> >
> > Is this the same scenario in your case ?
> > perhaps a simple test db could used to resolve if this is the issue !
>
>     Looks  like  a  deadlock  situation  not seen by the deadlock
>     detection code.  Unfortunately I'm not able  to  reproduce  a
>     lockup  with  a  simple  test  DB.   Could  you post a simple
>     (trans1 does  ...,  trans2  does  ...)  sample  so  we  coule
>     reproduce such a lockup?

Hi Jan,

I shall try to reproduce the lockup with  -d2 debug level but, I am not sure this
is the only
lockup problem as it seems far to frequent twice today already and thats in only
4 hours of use :(

Q1. When a system task on a client gets killed how long is it before the database
releases it's record locks ?

Q2. When the Postgres  server is shutdown and re started shouldn't all the record
locks have been removed ?

This situation seems to be getting worse, now I am scared to leave the building.

Regards,               Frank.




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: AW: AW: fmgr changes not yet ported to AIX
Next
From: Tom Lane
Date:
Subject: Re: AW: AW: AW: AW: Vacuum only with 20% old tuples