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
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 |