Re: [HACKERS] Patch: Implement failover on libpq connectlevel. - Mailing list pgsql-jdbc

From Tsunakawa, Takayuki
Subject Re: [HACKERS] Patch: Implement failover on libpq connectlevel.
Date
Msg-id 0A3221C70F24FB45833433255569204D1F6413C9@G01JPEXMBYT05
Whole thread Raw
In response to Re: [HACKERS] Patch: Implement failover on libpq connect level.  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-jdbc
From: pgsql-jdbc-owner@postgresql.org
> [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Craig Ringer
> >> If true, that's insane.  That can be different on each connection to
> >> the cluster and can change tens of thousands of times per second on
> >> any connection!
> >
> > I don't think that's insane.  The command is only being issued at
> > connection startup, and will only be different on different
> > connections if it's been configured that way.
> 
> I agree. However, I also think we should make sure add a GUC_REPORT var
> in v10 that lets a client tell whether it's connected to a read/write or
> read-only node right from the start. This will save an unnecessary
> round-trip and some annoying log-spam.

Yes, I meant the GUC_REPORT method.  I don't think something like read-only and read/write is intuitive as values
valuesof target_server_type, because people who want to use reporting apps that use temporary tables have to connect to
theprimary, because temp tables are not supported on standbys.  I think the current notion of primary/standby is good;
thosewho require temp tables need to specify primary.
 


> I'd rather not bind it directly to "in recovery" because we're likely to
> want to support read-only logical replication nodes in future, but even
> that would be OK.

Maybe we should determine the name and value of the connection parameter and GUC-REPORTed variable in light of the
logicalreplication.
 

Regards
Takayuki Tsunakawa


pgsql-jdbc by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] Patch: Implement failover on libpq connect level.
Next
From: Jorge Solórzano
Date:
Subject: Versioning policy PgJDBC - discussion