Re: Postgresql 9.1 pg_last_xact_replay_timestamp limitations - Mailing list pgsql-general

From Gabi Julien
Subject Re: Postgresql 9.1 pg_last_xact_replay_timestamp limitations
Date
Msg-id 201012091124.09451.gabi.julien@broadsign.com
Whole thread Raw
In response to Postgresql 9.1 pg_last_xact_replay_timestamp limitations  (Gabi Julien <gabi.julien@broadsign.com>)
Responses Re: Postgresql 9.1 pg_last_xact_replay_timestamp limitations  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-general
On Wednesday 08 December 2010 21:58:46 you wrote:
> On Thu, Dec 9, 2010 at 1:37 AM, Gabi Julien <gabi.julien@broadsign.com> wrote:
> > slave# /etc/init.d/postgresql start
> > slave# psql -hlocalhost my_db -c "select pg_last_xact_replay_timestamp(), now() as not_modified_since;"
> >  pg_last_xact_replay_timestamp |      not_modified_since
> > -------------------------------+-------------------------------
> >                               | 2010-12-08 16:06:09.920219+00

> We should return the timestamp of last valid checkpoint rather than NULL in that
> case?

Well, I think this behavior would be more appreciated by postgresql users in general. The case where the slave can be
restartedafter a clean shutdown is rare but we need to consider it nonetheless. In my case I implemented a custom
functionthat reads the last returned timestamp from a new file on disk. This is not a perfect solution since the value
returnedmight be older then the actual state of the replication but it's good enough for my needs. 

Regards,
Gabi Julien

pgsql-general by date:

Previous
From: Raimon Fernandez
Date:
Subject: Re: SELECT is immediate but the UPDATE takes forever
Next
From: "Jaiswal Dhaval Sudhirkumar"
Date:
Subject: calculation of database size