Re: timeout implementation issues
От | Bruce Momjian |
---|---|
Тема | Re: timeout implementation issues |
Дата | |
Msg-id | 200204011818.g31IIdd06139@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: timeout implementation issues (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: timeout implementation issues, lock timeouts
|
Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > ... It will be tricky to manage multiple > > alarms in a single process, but it can be done by creating an alarm > > queue. > > I would argue that we should only support *one* kind of timeout, either > transaction-level or statement-level, so as to avoid that complexity. > I don't want to see us gilding the lily in the first implementation of > something that IMHO is of dubious usefulness in the first place. > We can think about extending the facility later, when and if it proves > sufficiently useful to justify more complexity. > > I don't have a very strong feeling about whether transaction-level or > statement-level is more useful; am willing to do whichever one the > JDBC spec wants. Agreed, only one timeout. I just considered the statement/transaction level quite interesting. We could easily do GUC for query level, and allow BEGIN WORK to override that for transaction level. That would give us the best of both worlds, if we want it. I am not sure what people are going to use this timeout for. My guess is that only transaction level is the way to go. -- 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 по дате отправления: