Re: Lock timeout detection in postgres 7.3.1

>
> I have recently migrated my database from MS Sql
> Server to postgresql 7.3.1. In MS SQL SERVER, it is
> very easy to set the lock time equals to zero on ROW
> LEVEL. So that if some other user try to access the
> same data, he/she will get the error immediately. I
> have tried to run the same code through VB 6.0
> (windows) using pgsql as database on RED HAT LINUX
> 8.0, the only problem i am facing is when ever a user
> try to access a pre LOCKED ROW, the program goes into
> halt until the first user executes ROLLBACK or COMMIT.
>
> Is there any way to set the LOCK TIME equals to ZERO
> in postgresql 7.3.1?
>

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
check for deadlock is relatively slow, so we don't want to run it
every time we wait for a lock. We (optimistically?) assume that
deadlocks are not common in production applications, and just wait
on the lock for awhile before starting to ask questions
about whether it can ever get unlocked. Increasing this value
reduces the amount of time wasted in needless deadlock checks,
but slows down reporting of real deadlock errors. The default is
1000 (i.e., one second), which is probably about the smallest
value you would want in practice. On a heavily loaded server you
might want to raise it. Ideally the setting should exceed your
typical transaction time, so as to improve the odds that the lock
will be released before the waiter decides to check for
deadlock. This option can only be set at server start.

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.

Regards, Christoph