| From: | Nikhil Sontakke <nikkhils(at)gmail(dot)com> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: B-tree page deletion boundary cases |
| Date: | 2012-04-24 07:12:56 |
| Message-ID: | CANgU5ZePFi5ay=tiNA29woXi8GKDda8AOSL6VhS_3L3qX=2FZQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sandro Santilli | 2012-04-24 07:31:36 | Re: Gsoc2012 idea, tablesample |
| Previous Message | Boszormenyi Zoltan | 2012-04-24 07:00:36 | Re: [PATCH] lock_timeout and common SIGALRM framework |