Re: Implementing RESET CONNECTION ...

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Implementing RESET CONNECTION ...
Дата
Msg-id 11856.1104800213@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Implementing RESET CONNECTION ...  (Kris Jurka <books@ejurka.com>)
Ответы Re: Implementing RESET CONNECTION ...  (Oliver Jowett <oliver@opencloud.com>)
Список pgsql-patches
Kris Jurka <books@ejurka.com> writes:
> 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.

I haven't looked at the proposed patch, but I would've expected that it
duplicates the existing RESET ALL behavior for GUC settings.  And that
already works the way you want.  Values taken from the client connection
request packet establish the session defaults, ie, what RESET goes to.

> Also I don't like the idea of cleaning up prepared statements.

Hmm.  This seems a bit eye-of-the-beholder-ish, ie you could make a
legitimate argument either way.  Maybe the RESET CONNECTION command
should have an option whether to zap prepared statements or not?
Is there anything else falling in the category of "debatable"?

            regards, tom lane

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

Предыдущее
От: lsunley@mb.sympatico.ca
Дата:
Сообщение: Re: psql session log
Следующее
От: lsunley@mb.sympatico.ca
Дата:
Сообщение: logfile for psql patch update