Horton

Re: B-tree page deletion boundary cases

Nikhils <nikkhils@gmail.com>

View thread
From: Nikhil Sontakke <nikkhils@gmail.com>
To: Noah Misch <noah@leadboat.com>
Cc: pgsql-hackers@postgresql.org
Date: 2012-04-24T07:12:56Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Reduce impact of btree page reuse on Hot Standby by fixing off-by-1 error.

  2. Respect Hot Standby controls while recycling btree index pages.

> > Was wondering if there's a similar bug which gets triggered while using
> > VACUUM FULL. See for instance this thread:
> >
> >
> http://postgresql.1045698.n5.nabble.com/index-corruption-in-PG-8-3-13-td4257589.html
> >
> > This issue has been reported on-off from time to time and in most cases
> > VACUUM or VACUUM FULL appears to be involved. We have usually attributed
> it
> > to hardware issues and reindex has been recommended by default as a
> > solution/work around..
>
> I do not perceive much similarity.  The bug I've raised can produce wrong
> query results transiently.  It might permit injecting a tuple into the
> wrong
> spot in the tree, yielding persistent wrong results.  It would not
> introduce
> tree-structural anomalies like sibling pointers directed at zeroed pages or
> internal pages in an 1-level tree.  Given the symptoms you reported, I
> share
> Robert's suspicion of WAL replay in your scenario.
>

Thanks for taking the time to analyze this Noah.

Regards,
Nikhils