Re: Streaming replication and pg_xlogfile_name()

From: "Erik Rijkers" <er(at)xs4all(dot)nl>
To: "Fujii Masao" <masao(dot)fujii(at)gmail(dot)com>
Cc: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication and pg_xlogfile_name()
Date: 2010-02-25 21:26:33
Message-ID: e3bb26058e23ad57d9963695784a90f7.squirrel@webmail.xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, February 25, 2010 17:34, Fujii Masao wrote:
>
> I attached the revised patch which uses lastPageTLI instead of curFileTLI
> as the timeline of the last applied record.
>

With this patch the standby compiles, tests, installs OK.
I wanted to check with you if the following is expected.

With standby (correctly) as follows :
LOG: redo starts at 0/1000020
LOG: consistent recovery state reached at 0/2000000
LOG: database system is ready to accept read only connections

This is OK.

However, initially (even after the above 'ready' message)
the timeline value as reported by
pg_xlogfile_name_offset(pg_last_xlog_replay_location())
is zero.

After 5 minutes or so (without any activity on primary
or standby), it proceeds to 1 (see below):

(standby)
2010.02.25 21:58:21 $ psql
psql (9.0devel)
Type "help" for help.

replicas=# \x
Expanded display is on.
replicas=# select
pg_last_xlog_replay_location()
, pg_xlogfile_name_offset(pg_last_xlog_replay_location())
, pg_last_xlog_receive_location()
, pg_xlogfile_name_offset(pg_last_xlog_receive_location())
, now();
-[ RECORD 1 ]-----------------+------------------------------------
pg_last_xlog_replay_location | 0/0/2000000
pg_xlogfile_name_offset | (000000000000000000000001,16777216)
pg_last_xlog_receive_location | 1/0/2000000
pg_xlogfile_name_offset | (000000010000000000000001,16777216)
now | 2010-02-25 22:03:41.585808+01

replicas=# select
pg_last_xlog_replay_location()
, pg_xlogfile_name_offset(pg_last_xlog_replay_location())
, pg_last_xlog_receive_location()
, pg_xlogfile_name_offset(pg_last_xlog_receive_location())
, now();
-[ RECORD 1 ]-----------------+------------------------------------
pg_last_xlog_replay_location | 0/0/2000000
pg_xlogfile_name_offset | (000000000000000000000001,16777216)
pg_last_xlog_receive_location | 1/0/2000000
pg_xlogfile_name_offset | (000000010000000000000001,16777216)
now | 2010-02-25 22:06:56.008181+01

replicas=# select
pg_last_xlog_replay_location()
, pg_xlogfile_name_offset(pg_last_xlog_replay_location())
, pg_last_xlog_receive_location()
, pg_xlogfile_name_offset(pg_last_xlog_receive_location())
, now();
-[ RECORD 1 ]-----------------+-------------------------------
pg_last_xlog_replay_location | 1/0/20000B8
pg_xlogfile_name_offset | (000000010000000000000002,184)
pg_last_xlog_receive_location | 1/0/20000B8
pg_xlogfile_name_offset | (000000010000000000000002,184)
now | 2010-02-25 22:07:51.368363+01

I not sure this qualifies as a bug, but if not, it should probably be mentioned somewhere in the
documentation.

(Oh, and to answer Heikki's earlier question, "what you trying to achieve?": I am trying to keep
track of how far behind the standby is when I restore a large dump (500 GB or so) into the primary
(eventually I want at the same time run pgbench on both).)

thanks,

Erik Rijkers

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Omar Bettin 2010-02-25 21:35:52 feature request
Previous Message Tom Lane 2010-02-25 21:25:55 Re: A thought on Index Organized Tables