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