Re: InvalidXLogRecPtr in docs

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.

regards, tom lane