Horton

Re: Patch: Implement failover on libpq connect level.

Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>

View thread View on postgr.es
From: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
To: 'Tatsuo Ishii' <ishii@sraoss.co.jp>, "mithun.cy@enterprisedb.com" <mithun.cy@enterprisedb.com>
Cc: "robertmhaas@gmail.com" <robertmhaas@gmail.com>, "peter.eisentraut@2ndquadrant.com" <peter.eisentraut@2ndquadrant.com>, "pvh@pvh.ca" <pvh@pvh.ca>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-11-17T02:29:58Z
Lists: pgsql-hackers 
From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tatsuo Ishii
> In my understanding pg_is_in_recovery() returns true if it's a standby node.
> However, even if it returns other than true, the server is not necessarily
> a primary. Even it's not configured as a streaming replication primary,
> it returns other than true.
> 
> So if your intention is finding a primary, I am not sure if
> pg_is_in_recovery() is the best solution.

Yes, I don't think pg_is_in_recovery() is the best, but there doesn't seem to be a better solution.  pg_is_in_recovery(), as its name clearly suggests, returns true if the server is performing recovery.  For example, it returns true if hot_standby=on is present in postgresql.conf and the recovery from backup is in progress.  It's not a standby.

Regards
Takayuki Tsunakawa

Commits

  1. libpq: Add target_session_attrs parameter.

  2. Remove superuser checks in pgstattuple

  3. Fix unwanted flushing of libpq's input buffer when socket EOF is seen.