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

Re: [COMMITTERS] pgsql: Forbid using pg_xlogfile_name() and pg_xlogfile_name_offset()

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Subject: Re: [COMMITTERS] pgsql: Forbid using pg_xlogfile_name() and pg_xlogfile_name_offset()
Date: 2010-04-07 10:23:24
Message-ID: 4BBC5D1C.5050304@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
(moving to pgsql-hackers)

Simon Riggs wrote:
> On Wed, 2010-04-07 at 06:12 +0000, Heikki Linnakangas wrote:
>> Log Message:
>> -----------
>> Forbid using pg_xlogfile_name() and pg_xlogfile_name_offset() during
>> recovery. We might want to relax this in the future, but ThisTimeLineID
>> isn't currently correct in backends during recovery, so the filename
>> returned was wrong.
> 
> Any reason why we couldn't just do this:
> 
> if (RecoveryInProgress())
> {
> 	volatile XLogCtlData *xlogctl = XLogCtl;
> 	XLogFileName(xlogfilename, xlogctl->ThisTimeLineID, 
> 			xlogid, xlogseg);
> }
> else
> 	XLogFileName(xlogfilename, ThisTimeLineID, xlogid, xlogseg);
> 
> 
> rather than preventing access to those functions completely?

Because if you do something like
pg_xlogfile_name(pg_last_xlog_receive_location()),
xloctl->ThisTimeLineId would not necessarily be the timeline
corresponding the last received location. Even with
pg_xlogfile_name(pg_last_xlog_replay_location()), there's a small race
condition between those calls; if a checkpoint record is replayed in
between that changes timeline, the returned filename doesn't correspond
the name of the file where the replayed WAL record was read from, as you
would expect.

This commit is a stop-gap solution until we figure out what exactly to
do about that. Masao-san wrote a patch that included the TLI in the
string returned by pg_last_xlog_receive/replay_location() (see
http://archives.postgresql.org/message-id/3f0b79eb1003030603ibd0cbadjebb09fa4249304ba@mail.gmail.com
and
http://archives.postgresql.org/message-id/3f0b79eb1003300214r6cf98c46tc9be5d563ccf48db@mail.gmail.com),
but it still wasn't clear it did the right thing in corner-cases where
the TLI changes. Using GetRecoveryTargetTLI() for the tli returned by
pg_last_receive_location() seems bogus, at least.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2010-04-07 10:27:13
Subject: Re: BUG #5394: invalid declspec for PG_MODULE_MAGIC
Previous:From: Heikki LinnakangasDate: 2010-04-07 10:02:04
Subject: Re: Streaming replication and a disk full in primary

pgsql-committers by date

Next:From: Heikki LinnakangasDate: 2010-04-07 10:58:49
Subject: pgsql: Allow quotes to be escaped in recovery.conf, by doubling them.
Previous:From: Simon RiggsDate: 2010-04-07 09:41:36
Subject: Re: pgsql: Forbid using pg_xlogfile_name() and pg_xlogfile_name_offset()

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