Nagy Daniel writes:
> Here's a better backtrace:
The crash location suggests a problem with a corrupted tuple, but it's
impossible to guess where the tuple came from. In particular I can't
guess whether this reflects on-disk data corruption or some internal
bug. Now that you have (some of) the
(gdb) p debug_query_string
$1 = 12099472
Now I recompiled pg with --enable-debug and waiting for a new core dump.
I'll post the backtrace and the debug_query_string output ASAP.
Please let me know if there is anything more I can do.
Thanks,
Daniel
Tom Lane wrote:
> Nagy Daniel writes:
>> (g
Hi Guys,
Here you are:
na...@goldbolt:~$ gdb /usr/local/pgsql/bin/postgres core
GNU gdb 6.8-debian
...
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libm.so.6...done.
Loaded
Nagy Daniel writes:
> (gdb) p debug_query_string
> $1 = 12099472
Huh, your stripped build is being quite unhelpful :-(. I think
"p (char *) debug_query_string" would have produced something useful.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postg
Robert Haas writes:
>> I'm not sure this fixes it, although I haven't tested. When we take
>> the /* store first fractional byte */ branch, destbitsleft is between
>> 1 and 7 bits greater than srcbitsleft. We then subtract 8 from
>> destbitsleft, and the comment on the next line now asserts that
Woops, forgot to copy the list.
On Sat, Dec 12, 2009 at 2:15 PM, Robert Haas wrote:
> On Sat, Dec 12, 2009 at 2:00 PM, Tom Lane wrote:
>> Roman Kononov writes:
>>> The bitfromint8() and bitfromint4() are hosed. They produce wrong
>>> results when the BIT size is more than 64 and 32 respectively
Roman Kononov writes:
> The bitfromint8() and bitfromint4() are hosed. They produce wrong
> results when the BIT size is more than 64 and 32 respectively, and the
> BIT size is not multiple of 8, and the most significant byte of the
> integer value is not 0x00 or 0xff.
Hm, you're right, it's d
The bitfromint8() and bitfromint4() are hosed. They produce wrong
results when the BIT size is more than 64 and 32 respectively, and the
BIT size is not multiple of 8, and the most significant byte of the
integer value is not 0x00 or 0xff.
For example:
test=# select (11::int4<<23 | 11::int4):
Nagy Daniel writes:
> (gdb) backtrace
> #0 0x00453415 in slot_deform_tuple ()
> #1 0x0045383a in slot_getattr ()
> #2 0x00550dac in ExecHashGetHashValue ()
> #3 0x00552a98 in ExecHashJoin ()
> #4 0x00543368 in ExecProcNode ()
> #5 0x00552aa6 in
