Skip site navigation (1) Skip section navigation (2)

Re: get/setReadOnly broken if default_transaction_read_only on

From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
To: J Chapman Flack <jflack(at)math(dot)purdue(dot)edu>
Cc: pgsql-jdbc(at)postgresql(dot)org, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Subject: Re: get/setReadOnly broken if default_transaction_read_only on
Date: 2012-06-07 10:50:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
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

In response to


pgsql-jdbc by date

Next:From: J Chapman FlackDate: 2012-06-07 14:07:14
Subject: Re: get/setReadOnly broken if default_transaction_read_only on
Previous:From: Kevin GrittnerDate: 2012-06-06 20:49:53
Subject: Re: get/setReadOnly broken if default_transaction_read_only on

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group