From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | ARTEAGA Jose <Jose(dot)Arteaga(at)alcatel-lucent(dot)com>, pgsql-general(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Subject: | Re: Limitations on 7.0.3? |
Date: | 2007-07-17 14:07:18 |
Message-ID: | 22392.1184681238@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Richard Huxton <dev(at)archonet(dot)com> writes:
> I think tag_hash (in /backend/utils/hash/hashfn.c) is responsible for
> internal hash-tables (rather than hash indexes). It takes a pointer to a
> key to hash and a keysize (in bytes), so either the pointer is bad or
> the size is too long and it's reading off the end.
Those stack traces hardly seem credible --- the key being hashed is a
local variable in BufferAlloc, so the pointer can't really be bad,
and the length apparently is 12 as it should be. I was wondering if
maybe the hashp->hash function pointer got corrupted, but that seems
unlikely too seeing that it's part of a struct that never changes.
> If it's not a hardware related problem, then it's a bug, but you're
> unlikely to get a fix given how old the code is.
If you can reproduce the problem in something reasonably recent, we'd be
interested in taking a look. Nobody is going to spend any time on 7.0.x
though. It *will* eat your data someday ... you need to put more time
into getting off it and less into studying its bugs.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2007-07-17 14:32:15 | Sylph-Searcher 1.0.0 released |
Previous Message | ann hedley | 2007-07-17 14:04:59 | Re: average/stddev on all values returned by a select distinct |