Nagy Daniel nagy.dan...@telekom.hu 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
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::int423 |
Roman Kononov kono...@ftml.net 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
Woops, forgot to copy the list.
On Sat, Dec 12, 2009 at 2:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Dec 12, 2009 at 2:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Roman Kononov kono...@ftml.net writes:
The bitfromint8() and bitfromint4() are hosed. They produce wrong
results when
Robert Haas robertmh...@gmail.com 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
Nagy Daniel nagy.dan...@telekom.hu 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
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
(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
Nagy Daniel nagy.dan...@telekom.hu 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
