I wrote:
> Ugh. Mea culpa for letting this one through.
I've committed patches to fix this.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
I wrote:
> Jeff Janes writes:
>> Hash index is not concurrency safe, starting in REL8_4_0 and up to HEAD.
> Ouch. This used to be okay, because adding new entries to a hash page
> always added them at the end. The 8.4 changes to keep individual hash
> pages sorted by hashcode broke it :-(.
Act
Jeff Janes writes:
> On Sun, Nov 1, 2009 at 8:52 AM, Tom Lane wrote:
>> I think we could recover by having the hashgettuple code path
>> re-synchronize by looking for the heap TID it previously returned.
> Can it get pushed to another page (an overflow page)? My quick
> reading of the code sugg
On Sun, Nov 1, 2009 at 8:52 AM, Tom Lane wrote:
> "Jeff Janes" writes:
>> Hash index is not concurrency safe, starting in REL8_4_0 and up to HEAD.
>
> Ouch. This used to be okay, because adding new entries to a hash page
> always added them at the end. The 8.4 changes to keep individual hash
>
"Jeff Janes" writes:
> Hash index is not concurrency safe, starting in REL8_4_0 and up to HEAD.
Ouch. This used to be okay, because adding new entries to a hash page
always added them at the end. The 8.4 changes to keep individual hash
pages sorted by hashcode broke it :-(.
I think we could re
The following bug has been logged online:
Bug reference: 5157
Logged by: Jeff Janes
Email address: jeff.ja...@gmail.com
PostgreSQL version: 8.4.1
Operating system: Linux
Description:Hash index not concurrency safe
Details:
Hash index is not concurrency safe, startin
