Horton

Re: [REVIEW] pg_last_xact_insert_timestamp

Simon Riggs <simon@2ndquadrant.com>

View thread
From: Simon Riggs <simon@2ndQuadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@oss.ntt.co.jp>, "masao.fujii" <masao.fujii@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-09-30T20:07:58Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Treat 2PC commit/abort the same as regular xacts in recovery.

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.

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