Re: timeout on lock feature
От | Bruce Momjian |
---|---|
Тема | Re: timeout on lock feature |
Дата | |
Msg-id | 200104190139.f3J1ddO10137@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: timeout on lock feature (ncm@zembu.com (Nathan Myers)) |
Ответы |
Re: timeout on lock feature
|
Список | pgsql-hackers |
> On Wed, Apr 18, 2001 at 07:33:24PM -0400, Bruce Momjian wrote: > > > 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. > > > > Now that is a nifty idea. Just put it on one command, BEGIN, and have > > it apply for the whole transaction. We could just set an alarm and do a > > longjump out on timeout. > > Of course, it begs the question why the client couldn't do that > itself, and leave PG out of the picture. But that's what we've > been talking about all along. Yes, they can, but of course, they could code the database in the application too. It is much easier to put the timeout in a psql script than to try and code it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: