Re: [REVIEW] pg_last_xact_insert_timestamp

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>, "masao(dot)fujii" <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [REVIEW] pg_last_xact_insert_timestamp
Date: 2011-09-30 20:07:58
Message-ID: CA+U5nM+gdXCx2Gq4ZLVwjWBq7T-nzikzjO2Q6jpxi+G7OWxbNA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 30, 2011 at 8:57 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Sep 30, 2011 at 3:22 PM, Simon Riggs <simon(at)2ndquadrant(dot)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.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Farina 2011-10-01 01:25:02 pg_cancel_backend by non-superuser
Previous Message Robert Haas 2011-09-30 19:57:19 Re: [REVIEW] pg_last_xact_insert_timestamp