Re: Feature Request: pg_replication_master() - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Feature Request: pg_replication_master()
Date
Msg-id CABUevEyPPOZdqw1OYd3SHq9f6PjNT==Nhz-RWW1d-cvjC2ONLg@mail.gmail.com
Whole thread Raw
In response to Feature Request: pg_replication_master()  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Feature Request: pg_replication_master()  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Feature Request: pg_replication_master()  (Joshua Berkus <josh@agliodbs.com>)
List pgsql-hackers
<p dir="ltr"><br /> On Dec 19, 2012 4:43 AM, "Josh Berkus" <<a
href="mailto:josh@agliodbs.com">josh@agliodbs.com</a>>wrote:<br /> ><br /> > Hackers,<br /> ><br /> >
Currentlywe can see each master's current replicas using<br /> > pg_stat_replication.  However, there is no way from
areplica, that I<br /> > know of, to figure out who its master is other than to look at<br /> > recovery.conf.<br
/>><br /> > We should probably have a function, like pg_replication_master(), which<br /> > gives the host
addressof the current master.  This would help DBAs for<br /> > large replication clusters a lot.  Obviously, this
wouldonly work in<br /> > streaming.<br /><p dir="ltr">This sounds like my previous suggestion of returning the
primaryconninfo value, but with just ip. That one came with a pretty bad patch, and was later postponed until we folded
recovery.confinto the main configuration file parsing. I'm not really sure what happened to that project? (the
configurationfile one) <p dir="ltr">/Magnus  

pgsql-hackers by date:

Previous
From: Jeevan Chalke
Date:
Subject: Re: too much pgbench init output
Next
From: Magnus Hagander
Date:
Subject: Re: system administration functions with hardcoded superuser checks