From: Mithun Cy [mailto:mithun...@enterprisedb.com]
> > + {"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
advance.
Regards
Takayuki Tsunakawa
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
