From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'ncm(at)zembu(dot)com'" <ncm(at)zembu(dot)com> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | AW: timeout on lock feature |
Date: | 2001-04-19 09:24:29 |
Message-ID: | 11C1E6749A55D411A9670001FA687963368299@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > > 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.
>
> No. You wrote elsewhere that the application sets "30 seconds" and
> leaves it. But that 30 seconds doesn't have any application-level
> meaning
In interactive OLTP it does.
> -- an operation could take twelve hours without tripping your
> 30-second timeout.
Not in OLTP. Using the feature for a batch client with a low timeout
would be plain wrong.
> What might be a reasonable alternative would be a BEGIN timeout: report
> failure as soon as possible after N seconds unless the timer is reset,
> such as by a commit. Such a timeout would be meaningful at the
> database-interface level. It could serve as a useful building block
> for application-level timeouts when the client environment has trouble
> applying timeouts on its own.
I like that, but I do not think it is feasible.
I do not think that you can guarantee an answer within x seconds,
be it positive or negative. But that is what this feature would imply.
If the client needs to react within x sec there is no way around implementing this in
the client (there could be all kinds of trouble between client and backend).
On a very busy server (in OLTP that is the only real reason your query takes too
long other than waiting for a lock) you will produce still more work with this feature.
That is also partly why I think that a lock timeout feature really makes sense
for interactive OLTP clients. It is not a perfect solution, but it usually serves
the purpose very well and keeps the client simple. And I do not agree, that it
is an objective to keep the db code simple at the cost of making a standard client
more complex.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Vince Vielhaber | 2001-04-19 09:49:45 | Re: Re: No printable 7.1 docs? |
Previous Message | Tatsuo Ishii | 2001-04-19 05:21:07 | Re: Fix for psql core dumping on bad user |