Re: [REVIEW] pg_last_xact_insert_timestamp - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [REVIEW] pg_last_xact_insert_timestamp
Date
Msg-id CA+TgmoZqhmikcFOV4jb631a=u83N9BcRWZzqwKDZ9-tm9AFdpw@mail.gmail.com
Whole thread Raw
In response to Re: [REVIEW] pg_last_xact_insert_timestamp  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Mon, Dec 12, 2011 at 9:51 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Mon, Dec 12, 2011 at 2:47 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Mon, Dec 12, 2011 at 9:24 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> On Mon, Dec 12, 2011 at 1:45 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>>> It also strikes me that anything
>>>> that is based on augmenting the walsender/walreceiver protocol leaves
>>>> anyone who is using WAL shipping out in the cold.  I'm not clear from
>>>> the comments you or Simon have made how important you think that use
>>>> case still is.
>>>
>>> archive_timeout > 0 works just fine at generating files even when
>>> quiet, or if it does not, it is a bug.
>>>
>>> So I don't understand your comments, please explain.
>>
>> If the standby has restore_command set but not primary_conninfo, then
>> it will never make a direct connection to the master.  So anything
>> that's based on extending that protocol won't get used in that case.
>
> Got that, but now explain the reason for saying such people are "out
> in the cold".

By that I only meant that if we add a lag-monitoring feature that
relies on the streaming replication protocol, then people who are not
using the streaming replication replication protocol will be unable to
monitor lag (or at least, the will be unable to do it any better than
they can do it today).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [REVIEW] pg_last_xact_insert_timestamp
Next
From: Lars Kanis
Date:
Subject: Re: [PATCH] PostgreSQL fails to build with 32bit MinGW-w64