On Sun, 2010-02-07 at 21:33 -0500, Tom Lane wrote:
> That last problem is easy to fix, but I'm not at all sure what to do
> about the scan interlock problem. Thoughts?
AFAICS the problem doesn't exist in normal running.
_bt_page_recyclable() tests against RecentXmin, which includes the xmins
of
On Sun, 2010-02-07 at 21:33 -0500, Tom Lane wrote:
> Another issue is that it's not clear what happens in a Hot Standby
> slave --- it doesn't look like Simon put any interlocking in this
> area to protect slave queries against having the page disappear
> from under them. The odds of an actual pro
Tom Lane wrote:
> Whilst looking around for stuff that could be deleted thanks to removing
> old-style VACUUM FULL, I came across some code in btree that seems
> rather seriously buggy. For reasons explained in nbtree/README, we
> can't physically recycle a "deleted" btree index page until all
> t
I wrote:
> And there's another problem: _bt_pagedel is designed to recurse
> in certain improbable cases, but I think this is flat out wrong
> when doing WAL replay --- if the original process did recurse
> then it will have emitted a WAL record for each deleted page,
> meaning replay would try to
Whilst looking around for stuff that could be deleted thanks to removing
old-style VACUUM FULL, I came across some code in btree that seems
rather seriously buggy. For reasons explained in nbtree/README, we
can't physically recycle a "deleted" btree index page until all
transactions open at the ti
