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?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
