From: Mithun Cy [mailto:mithun.cy@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/USERSET transaction_read_only. transaction_read_only is a transaction attribute, not the server type. What
wewant to use to determine the connection target should be not only whether the transaction is read only, but also
otherattributes such as whether temporary tables can be used (only standby), maintenance commands can be executed
(VACUUMand ANALYZE can run when transaction_read_only is on, but not on standby), etc. And how about other DBMSs? Do
wereally 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