Skip site navigation (1) Skip section navigation (2)

Re: pg_last_xact_replay_timestamp meaning

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_last_xact_replay_timestamp meaning
Date: 2011-03-19 02:21:46
Message-ID: AANLkTinpDU5ms=w43-fpwh4t6PO0GXwR3z6=b2EvPKL5@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Mar 18, 2011 at 9:35 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Mar 18, 2011 at 7:23 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> I just applied a doc patch for pg_last_xact_replay_timestamp, and the
>> text now says:
>>
>>       <entry>Get timestamp of last transaction replayed during recovery.
>>        This is the time at which the commit or abort WAL record for that
>>        transaction was generated on the primary.
>>        If no transactions have been replayed during recovery, this function
>>        returns NULL.  Otherwise, if recovery is still in progress this will
>>        increase monotonically.  If recovery has completed then this value will
>>        remain static at the value of the last transaction applied during that
>>        recovery.  When the server has been started normally without recovery
>>        the function returns NULL.
>>
>> Is this really the last commit/abort record or the last WAL record?
>> What should it be?  Is the name of this function correct?  Do we care
>> only about commit/abort records? Why?
>
> Commit and abort records have a timestamp.  Other WAL records don't.

Incidentally, there's an open item related to this:

* pg_last_xact_replay_timestamp limitations
linking to http://archives.postgresql.org/message-id/201012071131.55211.gabi.julien@broadsign.com

I'm not sure why this is important enough to be worth being on this
list, but... is this resolved now?

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

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-03-19 02:22:22
Subject: Re: pgsql: Document the all-balls IPv6 address.
Previous:From: Andrew DunstanDate: 2011-03-19 02:19:09
Subject: Re: pgsql: Document the all-balls IPv6 address.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group