Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> One approach might be for the interface to take care of setting the query
> >> timeout before each query, and just ask the backend to handle timeouts
> >> per-query. So from the user's perspective, session-level timeouts would
> >> exist, but the backend would not have to worry about rolling back
> >> timeouts.
>
> > Yes, that would work, but libpq and psql would have trouble doing full
> > session timeouts.
>
> >From the backend's perspective it'd be a *lot* cleaner to support
> persistent timeouts (good 'til canceled) than one-shots. If that's
> the choice then let's let the frontend library worry about implementing
> one-shots.
>
> Note: I am now pretty well convinced that we *must* fix SET to roll back
> to start-of-transaction settings on transaction abort. If we do that,
> at least some of the difficulty disappears for JDBC to handle one-shot
> timeouts by issuing SETs before and after the target query against a
> query_timeout variable that otherwise acts like a good-til-canceled
> setting. Can we all compromise on that?
Added to TODO:
* Abort SET changes made in aborted transactions
We do have on_shmem_exit and on_proc_exit function call queues. Seems
we will need SET to create a queue of function calls containing previous
values of variables SEt in multi-statement transactions. If we execute
the queue in last-in-first-out order, the variables will be restored
properly.
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
