Re: InvalidXLogRecPtr in docs

On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Even then, we wouldn't need to start from the beginning of the WAL
>> segment AFAICS. The point is to start from the Redo pointer, not from
>> the checkpoint record, because as soon as we read the checkpoint record
>> we'll need to start applying WAL from the Redo pointer, which is
>> earlier. The WAL file boundaries don't come into play there.
>
> I don't believe it's a good idea to have SR not write full xlog segment
> files.  Consider for example the following scenario:
>
> 1. SR writes some xlog file from the middle.
> 2. Filesystem says "ah-hah, I know about sparse storage" and doesn't
>   allocate the first half of the file.
> 3. Failover: slave goes live.
> 4. xlog file gets recycled for re-use.
> 5. While reusing the file, we write into the first half ... or try to,
>   but there's no disk space.
> 6. PANIC.
>
> There are probably some other good reasons not to allow incomplete
> copies of WAL files to exist on the slave system, anyway.
>
> 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?

Regards,

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