Re: Postgresql 9.1 pg_last_xact_replay_timestamp limitations

From: Gabi Julien <gabi(dot)julien(at)broadsign(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Postgresql 9.1 pg_last_xact_replay_timestamp limitations
Date: 2010-12-09 16:24:09
Message-ID: 201012091124.09451.gabi.julien@broadsign.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Wednesday 08 December 2010 21:58:46 you wrote:
> On Thu, Dec 9, 2010 at 1:37 AM, Gabi Julien <gabi(dot)julien(at)broadsign(dot)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 restarted after a clean shutdown is rare but we need to consider it nonetheless. In my case I implemented a custom function that reads the last returned timestamp from a new file on disk. This is not a perfect solution since the value returned might be older then the actual state of the replication but it's good enough for my needs.

Regards,
Gabi Julien

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Raimon Fernandez 2010-12-09 16:26:27 Re: use a variable name for an insert in a trigger for an audit
Previous Message Raimon Fernandez 2010-12-09 16:08:41 Re: SELECT is immediate but the UPDATE takes forever

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2010-12-09 16:56:33 Re: Solving sudoku using SQL
Previous Message Andrew Dunstan 2010-12-09 16:01:41 Re: [PERFORM] Slow BLOBs restoring