Re: [PATCHES] Implementing RESET CONNECTION ...

Поиск
Список
Период
Сортировка
От A.M.
Тема Re: [PATCHES] Implementing RESET CONNECTION ...
Дата
Msg-id 38152.12.15.136.26.1145975307.squirrel@webmail.webopticon.org
обсуждение исходный текст
Ответ на Re: [PATCHES] Implementing RESET CONNECTION ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
To complete the connection pooling for multiple users, it would be great
to have a protocol level option to change roles semi-permanently (to
reduce permissions). RESET SESSION AUTHORIZATION would then bounce back to
that (new, set) role until another protocol-level role "rollback". This
would allow completely reusable connections per database while maintaining
a real sandbox for each connection.

On Tue, April 25, 2006 10:19 am, Bruce Momjian wrote:
>

> OK, what would people like done with this patch?  Our TODO list has:
>
>
> * -Add RESET CONNECTION command to reset all session state
>
>
> This would include resetting of all variables (RESET ALL), dropping of
> temporary tables, removing any NOTIFYs, cursors, open transactions,
> prepared queries, currval()s, etc.  This could be used  for connection
> pooling.  We could also change RESET ALL to have this functionality. The
> difficult of this features is allowing RESET ALL to not affect changes
> made by the interface driver for its internal use.  One idea is for this
> to be a protocol-only feature.  Another approach is to notify the protocol
> when a RESET CONNECTION command is used.
>
> This patch does everything except reset currval(), but the big missing
> item is that it doesn't handle the protocol issues outlined in the TODO
> item.  However, there also has been very little discussion on exactly how
> the protocol stuff would work.
>
> Should we add it for 8.2 and see if we get any problem reports?




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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCHES] Implementing RESET CONNECTION ...
Следующее
От: "Zeugswetter Andreas DCP SD"
Дата:
Сообщение: Re: [GENERAL] Concurrency problem building indexes