Re: get/setReadOnly broken if default_transaction_read_only on

On 06/07/2012 04:11 AM, J Chapman Flack wrote:
>
> Hi,
>
> I've found this in the git head so it applies to current versions.
>
> AbstractJdbc2Connection initializes its readOnly member to a
> hardcoded false instead of to 'show default_transaction_read_only'
> from the backend.
>
> That means two things: 1. getReadOnly() is wrong in case the
> backend has default_transaction_read_only on, and
>
> 2. setReadOnly(false) doesn't work in that case, because the value
> is compared to readOnly and looks the same, so no set session
> characteristics command is sent to the backend.
>
>
> An application can work around (2) by always calling
> setReadOnly(true);setReadOnly(false); if it wants to write.
> But that's a bit ugly.
>
> The driver could do that too for a quick hack, but it would
> be nice to query the correct value from the backend and use that.

This may be an opportunity to improve how PgJDBC finds out important
details about the backend in general.

Right now, lots of things require individual queries of GUCs via SHOW
commands or other misc queries. A typical JDBC session may do several
round trips before running its first real query, and it's only going to
get worse.

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.

(Why extensibility? Because various layers - ORMs, query builders, etc
etc etc - tend to ask for more GUCs, and having the JDBC driver able to
immediately return them without more round trips would be great).

I'm dreaming of a situation where the JDBC driver sends a list of GUCs
it wants values for, caches the results, and most importantly keeps them
up to date by capturing the value sent in any SET commands issued via
the driver on that session.

This has been in the back of my mind a bit lately, as I look at the spew
of SHOW commands and similar shown when log_statement=all is enabled and
something like Hibernate/JPA2 is talking to the database.

--
Craig Ringer