Re: Ticket 128: Hot Standby and Streaming Replication

2010/2/10 Guillaume Lelarge <guillaume(at)lelarge(dot)info>:
> Le 03/02/2010 22:00, Guillaume Lelarge a écrit :
>> Le 03/02/2010 21:26, Magnus Hagander a écrit :
>>> On Wed, Feb 3, 2010 at 21:22, Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
>>>> Le 03/02/2010 21:04, Magnus Hagander a écrit :
>>>>> On Wed, Feb 3, 2010 at 00:11, Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I tried both of them yesterday night and tonight to have a look at what
>>>>>> could be done on pgAdmin for these features. AFAICT, not a lot.
>>>>>>
>>>>>> Actually, I have a really small patch that adds some informations in the
>>>>>> server panel. This information is quite simple. It tells the user if the
>>>>>> selected server is in recovery mode and the last xlog replay location.
>>>>>> I'm not sure we can do more. Streaming Replication can be detected if
>>>>>> max_wal_senders is greater than zero, but I'm not sure we really need to
>>>>>> add this kind of information on the server panel.
>>>>>
>>>>> It would be interesting to know *which* slaves are connected to a master, no?
>>>>>
>>>>
>>>> AFAICT, there is no way to know that automatically in Hot Standby and in
>>>> Streaming Replication. If you know some way to get that, I'm really
>>>> interested. At first, I had hoped I could at least get the conninfo
>>>> string on the slave, but recovery parameters are not available via show.
>>>
>>> Hmm. In that case, a way to do it should perhaps be created :-)
>>>
>>
>> This means working on patch for the Streaming Replication. Could be
>> interesting, but not something I can do right now.
>>
>
> This new version of the patch adds support for
> pg_last_xlog_receive_location().
>
> During FOSDEM, I discussed with Heikki about some interesting (at least
> for us) informations: mainly knowing who the master is and knowing who
> the slaves are.
>
> He confirmed me there is actually no way to get that information.
> There's also no way to have the contents of recovery.conf available as
> all other GUCs. We found that we could at least read the recovery.conf
> file in the master with pg_file_read, which will give us the master host
> (via the primary_conninfo parameter) for people using the adminpack
> module contrib. Is it something interesting enough that I put some time
> to code this? or do we stop here, commit what I already have and see
> later what's coming next? (the "what's coming next" could be something I
> would code for next release)

Parsing primary_conninfo certainly seems *really* ugly. I think we put
in what you have so far, and then lobby Heikki to get better functions
already in 9.0 :-)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/