Re: InvalidXLogRecPtr in docs - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: InvalidXLogRecPtr in docs
Date
Msg-id AANLkTinCyX3zcDB3wNYSVEWbtzjJ-N3cscGN350uGHW4@mail.gmail.com
Whole thread Raw
In response to Re: InvalidXLogRecPtr in docs  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: InvalidXLogRecPtr in docs  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Jun 15, 2010 at 2:41 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 15/06/10 08:23, Fujii Masao wrote:
>>
>> On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane<tgl@sss.pgh.pa.us>  wrote:
>>>
>>> I'm not sure if it's worth the trouble, or even a particularly smart
>>> idea, to force the output of the status function to be monotonic
>>> regardless of what happens underneath.  I think removing that claim
>>> from the docs altogether is the easiest answer.
>>
>> We should
>>
>> (1) just remove "While streaming replication is in progress this will
>>     increase monotonically." from the description about
>> pg_last_xlog_receive_location()?
>>
>> or
>>
>> (2) add "But if streaming replication is restarted this will back off
>>     to the beginning of current WAL file" into there?
>>
>> I'm for (2) since it's more informative. Thought?
>
> Something like (2) seems better, because even if we remove the note that it
> increases monotonically, people might still assume that.

The attached patch adds the following:

-------------
But when streaming replication is
restarted this will back off to the replication starting position,
which typically indicates the beginning of the WAL file including the
record in the position which <function>pg_last_xlog_replay_location</>
points to at the moment.
-------------

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Attachment

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [BUGS] Server crash while trying to read expression using pg_get_expr()
Next
From: Fujii Masao
Date:
Subject: Re: Proposal for 9.1: WAL streaming from WAL buffers