Re: [HACKERS] Hashjoin status report - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Hashjoin status report
Date
Msg-id 10226.926024607@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Hashjoin status report  (The Hermit Hacker <scrappy@hub.org>)
Responses Re: [HACKERS] Hashjoin status report  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Hashjoin status report  (The Hermit Hacker <scrappy@hub.org>)
Re: [HACKERS] Hashjoin status report  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Re: [HACKERS] Hashjoin status report  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
The Hermit Hacker <scrappy@hub.org> writes:
>> Opinions?  Should I plow ahead, or leave this to fix after 6.5 release?

> Estimate of time involved to fix this?  vs likelihood of someone
> triggering the bug in production?

I could probably get the coding done this weekend, unless something else
comes up to distract me.  It's the question of how much testing it'd
receive before release that worries me...

As for the likelihood, that's hard to say.  It's very easy to trigger
the bug as a test case.  (Arrange for a hashjoin where the inner table
has a lot of identical rows, or at least many sets of more-than-10-
rows-with-the-same-value-in-the-field-being-hashed-on.)  In real life
you'd like to think that that's pretty improbable.

What started this go-round was Contzen's report of seeing the
"hash table out of memory. Use -B parameter to increase buffers"
message in what was evidently a real-life scenario.  So it can happen.
Do you recall having seen many complaints about that error before?
        regards, tom lane


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Hashjoin status report
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Hashjoin status report