On Sun, Oct 2, 2011 at 12:10 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Sep 30, 2011 at 4:07 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On Fri, Sep 30, 2011 at 8:57 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Fri, Sep 30, 2011 at 3:22 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>>> If the feature could not be done another way, easily, I might agree.
>>>
>>> I don't see that you've offered a reasonable alternative. The
>>> alternative proposals that you proposed don't appear to me to be
>>> solving the same problem. AIUI, the requested feature is to be able
>>> to get, on the master, the timestamp of the last commit or abort, just
>>> as we can already get the timestamp of the last commit or abort
>>> replayed on the standby. Nothing you WAL log and no messages you send
>>> to the standby are going to accomplish that goal.
>>
>> The goal of the OP was to find out the replication delay. This
>> function was suggested, but its not the only way.
>>
>> My alternative proposals solve the original problem in a better way.
>
> As far as I can see, they don't solve the problem at all. Your
> proposals involve sending additional information from the master to
> the slave, but the slave already knows both its WAL position and the
> timestamp of the transaction it has most recently replayed, because
> the startup process on the slave tracks that information and publishes
> it in shared memory. On the master, however, only the WAL position is
> centrally tracked; the transaction timestamps are not.
The problem is to find the replication delay, even when the system is quiet.
What I have proposed finds the replication delay more accurately even
than looking at the last commit, since often there are writes but no
commits.
If we focus on the problem, rather than the first suggested solution
to that problem, we'll come out on top.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services