AW: timeout on lock feature

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: AW: timeout on lock feature
Date: 2001-04-18 07:54:11
Message-ID: 11C1E6749A55D411A9670001FA687963368290@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> > In short, I think lock timeout is a solution searching in vain for a
> > problem. If we implement it, we are just encouraging bad > application
> > design.
>
> I agree with Tom completely here.
>
> In any real-world application the database is the key component of a
> larger system: the work it does is the most finicky, and any mistakes
> (either internally or, more commonly, from misuse) have the most
> far-reaching consequences. The responsibility of the database is to
> provide a reliable and easily described and understood mechanism to
> build on.

It is not something that makes anything unrelyable or less robust.
It is also simple: "I (the client) request that you (the backend) dont wait for
any lock longer than x seconds"

> 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.

I think you are talking about different kinds of timeouts here.

> The only way PG could apply reasonable timeouts would be for the
> application to dictate them,

That is exactly what we are talking about here.

> but the application can better implement them itself.

It can, but it makes the program more complicated (needs timers or threads,
which violates your last statement "simplest interface".

>
> You can think of this as another aspect of the "end-to-end" principle:
> any system-level construct duplicated in a lower-level system component
> can only improve efficiency, not provide the corresponding high-level
> service. If we have timeouts in the database, they should be there to
> enable the database to better implement its abstraction, and not pretend
> to be a substitute for system-level timeouts.

Mentioned functionality has nothing to do with above statement which
I can fully support.

> There's no upper limit on how complicated a database interface can
> become (cf. Oracle). The database serves its users best by having
> the simplest interface that can possibly provide the needed service.

Agreed.

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB 2001-04-18 08:12:34 AW: Re: timeout on lock feature
Previous Message Tom Lane 2001-04-18 06:05:55 Re: [BUG] views and functions on relations