On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane <[email protected]> wrote:
> Heikki Linnakangas <[email protected]> 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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
