Re: timeout implementation issues - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: timeout implementation issues
Date
Msg-id Pine.LNX.4.30.0204070001260.683-100000@peter.localdomain
Whole thread Raw
In response to Re: timeout implementation issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: timeout implementation issues  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane writes:

> 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?

No.

I agree that there may be some variables that must be rolled back, or
where automatic reset on transaction end may be desirable (note that these
are two different things), but for some variables it's completely
nonsensical.  Those variables describe session characteristics, not
database state.  For instance, time zone, default_transaction_isolation.
Or consider you're raising the debug level, but it gets reset during
commit so you can't debug the commit process.  Or in the future we may
have some SQL-compatible always-in-transaction mode which would mean that
you could never set any variable to last.

If you want something that's transaction-specific, invent a new mechanism.
Hook in the set transaction isolation level command while you're at it.
But don't break everything that's worked so far.

-- 
Peter Eisentraut   peter_e@gmx.net



pgsql-hackers by date:

Previous
From: Barry Lind
Date:
Subject: Re: timeout implementation issues
Next
From: Tom Lane
Date:
Subject: Re: timeout implementation issues