| 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: | Whole Thread | Raw Message | 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 |