Re: Implementing RESET CONNECTION ...

Поиск
Список
Период
Сортировка
От Kris Jurka
Тема Re: Implementing RESET CONNECTION ...
Дата
Msg-id Pine.BSO.4.56.0501031603100.3834@leary.csoft.net
обсуждение исходный текст
Ответ на Implementing RESET CONNECTION ...  (Hans-Jürgen Schönig <postgres@cybertec.at>)
Ответы Re: Implementing RESET CONNECTION ...  (Hans-Jürgen Schönig <postgres@cybertec.at>)
Re: Implementing RESET CONNECTION ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-patches

On Thu, 30 Dec 2004, [ISO-8859-1] Hans-J�rgen Sch�nig 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

В списке pgsql-patches по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Bgwriter behavior
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: psql session log