Re: Lock timeout detection in postgres 7.3.1

--- Christoph Haller <ch(at)rodos(dot)fzk(dot)de> wrote:
>
> I'm working on
> PostgreSQL 7.2.3 on hppa-hp-hpux10.20, compiled by
> GCC 2.95.2
> and found a similar behaviour.
>
> T1 (within psql):
> BEGIN; DELETE FROM <some_table> ;
> DELETE n
>
> T2 (within psql):
> BEGIN; DELETE FROM <some_table> ;
> <waiting forever>
>
> The documentation says (within Server Runtime
> Environment)
> DEADLOCK_TIMEOUT (integer)
>
> This is the amount of time, in milliseconds, to
> wait on a lock
> before checking to see if there is a deadlock
> condition or not. The

> If I get this right, the T2 psql process should
> terminate within one
> second, shouldn't it?
> The postgresql.conf file is as it was right after
> the installation
> #deadlock_timeout = 1000
>
> So, I doubt this a bug, but still, there must be a
> misunderstanding or
> something else
> I don't know about. Could someone please enlighten
> us.
>

I don't think there is a deadlock in the example
given above. If I'm not mistaken a deadlock occurs if
both transactions are waiting for each other to
release the lock (i.e T1 waits for T2 to release
locks/resources while T2 is also waiting for T1 to
release locks/resources. In the above example, T1
doesn't wait for T2 to do something before finishes
the transaction (Only T2 is waiting for T1 to finish),
hence the condition for deadlock is not met.

ludwig.

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com