Re: Patch: Implement failover on libpq connect level. - Mailing list pgsql-hackers

From Mithun Cy
Subject Re: Patch: Implement failover on libpq connect level.
Date
Msg-id CAD__OujrhLNB6QtWLxZtvJt5n=gT+waWtRMLSLk=7J+fiOAFqg@mail.gmail.com
Whole thread Raw
In response to Re: Patch: Implement failover on libpq connect level.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Patch: Implement failover on libpq connect level.  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Re: Patch: Implement failover on libpq connect level.  (Robert Haas <robertmhaas@gmail.com>)
Re: Patch: Implement failover on libpq connect level.  (Kevin Grittner <kgrittn@gmail.com>)
List pgsql-hackers
> So I am tempted to just
> hold my nose and hard-code the SQL as JDBC is presumably already
doing.  

JDBC is sending "show transaction_read_only" to find whether it is master or not.
Victor's patch also started with it, but later it was transformed into pg_is_in_recovery
by him as it appeared more appropriate to identify the master / slave.

ConnectionFactoryImpl.java:685

+ private boolean isMaster(QueryExecutor queryExecutor, Logger logger)
+ throws SQLException, IOException {
+    byte[][] results = SetupQueryRunner.run(queryExecutor, "show transaction_read_only", true);
+    String value = queryExecutor.getEncoding().decode(results[0]);
+    return value.equalsIgnoreCase("off");
}

--
Thanks and Regards
Mithun C Y

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Push down more UPDATEs/DELETEs in postgres_fdw
Next
From: Craig Ringer
Date:
Subject: Re: [PATCH] Logical decoding timeline following take II