From: | Theo Kramer <theo(at)flame(dot)co(dot)za> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: timeout on lock feature |
Date: | 2001-04-18 04:34:54 |
Message-ID: | 200104180434.f3I4Ys322280@flame.co.za |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Timeouts are a system-level mechanism that to be useful must refer to
> system-level events that are far above anything that PG knows about.
> The only way PG could apply reasonable timeouts would be for the
> application to dictate them, but the application can better implement
> them itself.
OK we have the following scenario
Session A Session B
begin begin
insert -- on unique constraint
insert -- on same unique constraint
-- Session A becomes idle
: -- Session B becomes ...
or we have (Informix Online)
Session A Session B
set lock mode to wait [seconds] set lock mode to wait [seconds]
begin begin
insert -- on unique constraint
insert -- on same unique constraint
* resource not available error *
-- Session B carries on
Oracle 7 (OCI) has oopt() call to set wait options for requested
resources. Oracle 8 OCI has the same behaviour as PG ie. oopt()
is no longer available.
I believe that the ability to switch the database to either not wait
for resources, or wait a specified period or wait forever
(default) is essential especially for interactive applications.
Regards
Theo
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2001-04-18 04:48:24 | Re: Re: No printable 7.1 docs? |
Previous Message | Tom Lane | 2001-04-18 04:30:59 | Re: plpgsql problem |