On Tue, Oct 12, 2010 at 10:37:00AM -0500, Kevin Grittner wrote:
> David Fetter <david@fetter.org> wrote:
> > Is there something incomplete about the ones I sent, and if so,
> > what?
>
> Well, I'm still curious why it was necessary to modify the server
> side to implement an interface feature for which everything needed
> seems to be present on the client side.
Not everything is.
Let's imagine you have a connection pooler with two clients, A and B.
A calls setQueryTimeout, then starts a query, which terminates in
time, but dies before handling it. B connects to the pool, gets A's
connection, and finds a statement_timeout that's not the default, even
though only A's single query was supposed to have that
statement_timeout. This is not a situation that can be resolved
without being able to set a timer *on the server side*.
> Is this intended to be useful for other interfaces?
Anybody doing similar functionality, namely a per-statement timeout,
would need this infrastructure, and for the same reason.
> If so, we should probably have an implementation in some other
> interface to confirm that the server-side support fits. If not, why
> touch the server side code at all?
See above.
While I'd *like* to put in a whole infrastructure for setting GUCs on
a per-statement basis, I don't believe that we need to get out that
giant sledgehammer for this case, even though it's worth solving.
Incidentally, this dovetails neatly with the isolation concerns that
motivated the "true serializability" patch you're working on :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate