Re: Failure while inserting parent tuple to B-tree is not fun

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Failure while inserting parent tuple to B-tree is not fun
Date: 2014-02-04 00:40:33
Message-ID: CAM3SWZTORu0L2AdUGSk9KMOtW3vCqCb14vjfDTHTwYEracYcQA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 31, 2014 at 9:09 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> I refactored the loop in _bt_moveright to, well, not have that bug anymore.
> The 'page' and 'opaque' pointers are now fetched at the beginning of the
> loop. Did I miss something?

I think so, yes. You still aren't assigning the value returned by
_bt_getbuf() to 'buf'. Since, as I mentioned, _bt_finish_split()
ultimately unlocks *and unpins*, it may not be the same buffer as
before, so even with the refactoring there are race conditions. A
closely related issue is that you haven't mentioned anything about
buffer pins/refcount side effects in comments above
_bt_finish_split(), even though I believe you should.

A minor stylistic concern is that I think it would be better to only
have one pair of _bt_finish_split()/_bt_getbuf() calls regardless of
the initial value of 'access'.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-02-04 01:09:01 Re: pgsql: Document a few more regression test hazards.
Previous Message Gurjeet Singh 2014-02-04 00:18:54 Proposing pg_hibernate