Re: Implementing RESET CONNECTION ...

From: Kris Jurka <books(at)ejurka(dot)com>
To: Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>
Cc: pgsql-patche(at)postgresql(dot)org, pgman(at)candle(dot)pha(dot)pa(dot)us, eg(at)cybertec(dot)at, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Implementing RESET CONNECTION ...
Date: 2005-01-03 21:17:40
Message-ID: Pine.BSO.4.56.0501031603100.3834@leary.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Thu, 30 Dec 2004, [ISO-8859-1] Hans-Jrgen Schnig wrote:

> We have implemented a patch which can be used by connection pools for
> instance. RESECT CONNECTION cleans up a backend so that it can be
> reused. Temp tables, LISTEN / NOTIFY stuff, WITH HOLD cursors, open
> transactions, prepared statements and GUCs are cleaned up. I hope we
> have not missed important per-backend information.
>

From the JDBC driver's perspective this doesn't meet the needs I'd like to
see in a connection reset. In the initial connection setup a number of
GUC variables are tweaked to what the JDBC driver desires (DateStyle,
client_encoding). When resetting we'd want to reset to this point, not
the default values. Perhaps some kind of MARK command, kind of like a
savepoint to rollback to would better specify this.

Also I don't like the idea of cleaning up prepared statements. While it
doesn't do so now, the JDBC driver would like to do statement pooling at
some point. This means the same underlying server prepared statement can
be reused transparently from multiple callers. In a connection pool where
a connection is grabbed and returned for virtually each sql execution this
is key to getting the performance boost from prepared statements. We
don't want to have to reprepare on each connection and we don't want them
to disappear from underneath us, because the prepared statements are
generated transparently by the JDBC driver, not directly by a user
statement.

Kris Jurka

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message ntinos 2005-01-03 21:18:19 Re: Can't find relation oid
Previous Message Martijn van Oosterhout 2005-01-03 21:05:47 Re: Can't find relation oid

Browse pgsql-patches by date

  From Date Subject
Next Message Peter Eisentraut 2005-01-03 21:47:52 Re: psql session log
Previous Message Heikki Linnakangas 2005-01-03 20:52:00 ipcrm or ipcclean hint