| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> | 
| Cc: | "Johann 'Myrkraverk' Oskarsson" <johann(at)2ndquadrant(dot)com>, PostgreSQL JDBC <pgsql-jdbc(at)postgresql(dot)org> | 
| Subject: | Re: get/setReadOnly broken if default_transaction_read_only on | 
| Date: | 2012-06-08 13:47:19 | 
| Message-ID: | 11465.1339163239@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-jdbc | 
Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> writes:
> On 06/08/2012 04:19 PM, Johann 'Myrkraverk' Oskarsson wrote:
>> Craig Ringer<ringerc(at)ringerc(dot)id(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mike Charnoky | 2012-06-08 14:20:47 | Hung JDBC connections | 
| Previous Message | Craig Ringer | 2012-06-08 13:43:34 | Re: Connection.isValid(int timeout) implementation |