On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakan...@enterprisedb.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers