From: Mithun Cy []
> > +       {"target_server_type", "PGTARGETSERVERTYPE",
> DefaultTargetServerType, NULL,
> > +               "Target-Server-Type", "", 6,
> Thanks fixed.

+       {"target_server_type", "PGTARGETSERVERTYPE", NULL, NULL,

The default value field is still NULL.

> > Please avoid adding another round trip by using a GUC_REPORTed variable
> (ParameterStatus entry).  If you want to support this libpq failover with
> >pre-10 servers, you can switch the method of determining the primary based
> on the server version.  But I don't think it's worth supporting older
> servers > at the price of libpq code complexity.
> Currently there is no consensus around this. For now, making this patch
> to address failover to next primary as similar to JDBC seems sufficient
> for me.
> On next proposal of patch I think we can try to extend as you have proposed

I don't think show transaction is correct, because it's affected by 
default_transaction_read_only and ALTER DATABASE/USER SET 
transaction_read_only.  transaction_read_only is a transaction attribute, not 
the server type.  What we want to use to determine the connection target should 
be not only whether the transaction is read only, but also other attributes 
such as whether temporary tables can be used (only standby), maintenance 
commands can be executed (VACUUM and ANALYZE can run when transaction_read_only 
is on, but not on standby), etc.  And how about other DBMSs?  Do we really want 
to determine the target based on transaction_read_only while e.g. Oracle is 
based on primary/standby?

If you really want the transaction_read_only attribute for your application, 
then your app should execute "SET default_transaction_read_only = on" upon 
connection, or ALTER DATABASE/USER SET default_transaction_read_only = on in 

Takayuki Tsunakawa

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to