Re: get/setReadOnly broken if default_transaction_read_only on

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: get/setReadOnly broken if default_transaction_read_only on
Дата
Msg-id 11465.1339163239@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: get/setReadOnly broken if default_transaction_read_only on  (Craig Ringer <ringerc@ringerc.id.au>)
Ответы Re: get/setReadOnly broken if default_transaction_read_only on
Список pgsql-jdbc
Craig Ringer <ringerc@ringerc.id.au> writes:
> On 06/08/2012 04:19 PM, Johann 'Myrkraverk' Oskarsson wrote:
>> Craig Ringer<ringerc@ringerc.id.au>  writes:
>>> The JDBC driver really needs a way to grab everything it needs to know
>>> efficiently during initial connection setup, with some extensibility
>>> so connection parameters can specify other things to request and cache
>>> when the connection is first established.

> I was thinking more of running something like:
> ... preferably combined with a mechanism for the server to notify (or
> NOTIFY) the JDBC client when a pg_ctl reload or a SET causes settings to
> change.

Running pg_settings() seems like a dead end to me, precisely because you
won't know about any subsequent changes; and most of the parameters that
JDBC might care about are changeable.  LISTEN/NOTIFY is not the answer
either, for the reasons you mention as well as some others.

There already is a mechanism to notify clients of changes in selected
GUC settings, but currently the set of parameters so reported is
hard-wired.  Possibly pgsql-hackers would consider a proposal to let
the GUC_REPORT flag get set on client-selected parameters.

            regards, tom lane

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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Connection.isValid(int timeout) implementation
Следующее
От: Mike Charnoky
Дата:
Сообщение: Hung JDBC connections