Re: Is Pg 7.0.x's Locking Mechanism BROKEN?
От | frank |
---|---|
Тема | Re: Is Pg 7.0.x's Locking Mechanism BROKEN? |
Дата | |
Msg-id | 3980EBA3.B5B4685A@ieee.org обсуждение исходный текст |
Ответ на | Re: Re: [GENERAL] Is Pg 7.0.x's Locking Mechanism BROKEN? (JanWieck@t-online.de (Jan Wieck)) |
Ответы |
Re: Is Pg 7.0.x's Locking Mechanism BROKEN?
|
Список | 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 по дате отправления: