Re: Patch: Implement failover on libpq connect level.

From: Mithun Cy [mailto:mithun(dot)cy(at)enterprisedb(dot)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