_hash_addovflpage has a bug

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: _hash_addovflpage has a bug
Date: 2017-01-06 21:03:55
Message-ID: CA+TgmoYz2VMC0=zC-xADvb_7Jn1oif+dKeDRmS0owCy2EajxfA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

It looks to to me like the recent hash index changes have left
_hash_addovflpage slightly broken. I think that if that function
reaches the point where it calls _hash_getbuf() to fetch the next page
in the bucket chain, we also need to clear retain_pin. Otherwise,
we'll erroneously think that we're supposed to retain a pin even when
the current page is an overflow page rather than the primary bucket
page, which is wrong.

A larger question, I suppose, is why this function wants to be certain
of adding a new page even if someone else has already done so. It
seems like it might be smarter for it to just return the newly added
page to the caller and let the caller try to use it. _hash_doinsert
has an Assert() that the tuple fits on the returned page, but that
could be deleted. As it stands, if two backends try to insert a tuple
into the same full page at the same time, both of them will add an
overflow page and we'll end up with 2 overflow pages each containing 1
tuple.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2017-01-06 21:33:46 Re: ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type
Previous Message Tom Lane 2017-01-06 20:45:11 Re: Add support for SRF and returning composites to pl/tcl