On Fri, Nov 9, 2012 at 3:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > During normal running, operations such as btree page splits are > extremely careful about the order in which they acquire and release > buffer locks, if they're doing something that concurrently modifies > multiple pages. > > During WAL replay, that all goes out the window. Even if an individual > WAL-record replay function does things in the right order for "standard" > cases, RestoreBkpBlocks has no idea what it's doing. So if one or more > of the referenced pages gets treated as a full-page image, we are left > with no guarantee whatsoever about what order the pages are restored in. > That never mattered when the code was originally designed, but it sure > matters during Hot Standby when other queries might be able to see the > intermediate states. > > I can't prove that this is the cause of bug #7648,
(I was the reporter of 7648) To lend slightly more circumstantial evidence in support of this, I also happened to note that the relfile in question was the last segment and it was about a quarter full, so the access attempt was definitely at the extreme outermost edge of the index most generally. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
