On 2 April 2013 02:53, Jeff Davis <pgsql@j-davis.com> wrote:
>> Any idea
>> what is going on?
>
> Not right now.
Since I'm now responsible for the quality of this patch, I need to say
this before someone else does: we have until the end of the week to
fix this conclusively, or I will need to consider whether to revoke
the patch in this release. Thanks for your time and trouble to locate
problems.
It may be that the patch is revealing an underlying bug, so we don't
yet have evidence for the source of the bug.
> My primary suspect is what's going on in
> visibilitymap_set() and heap_xlog_visible(), which is more complex than
> some of the other code. That would require some VACUUM activity, which
> isn't in your workload -- do you think autovacuum may kick in sometimes?
Other candidates might be:
* page hole is non-empty, so the overwrite of the "Full" page write
may leave the block in an intermediate state. Tom recently fixed
RestoreBkpBlock() to avoid it zeroing the contents first before
applying the page.
* something to do with access to GetPageLSN()
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services