Re: Postgresql Segfault in 8.1

Version: postgresql-8.1.0-4.c4

I'll have to see about getting an update...

Thanks a TON,

-Ben

On Wednesday 25 January 2006 13:11, you wrote:
> Benjamin Smith <lists(at)benjamindsmith(dot)com> writes:
> > Aha, yep. Sorry:
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x000000000043c82c in heap_modifytuple ()
> > (gdb) bt
> > #0 0x000000000043c82c in heap_modifytuple ()
> > #1 0x000000000043c8f5 in slot_getattr ()
> > #2 0x000000000047a50a in FormIndexDatum ()
> > #3 0x00000000004ebee3 in ExecInsertIndexTuples ()
> > #4 0x00000000004e5265 in ExecutorRun ()
> > #5 0x0000000000564312 in FreeQueryDesc ()
> > #6 0x0000000000565287 in PortalRun ()
> > #7 0x0000000000560f8b in pg_parse_query ()
> > #8 0x0000000000562e0e in PostgresMain ()
> > #9 0x000000000053d316 in ClosePostmasterPorts ()
> > #10 0x000000000053ea59 in PostmasterMain ()
> > #11 0x00000000005033c3 in main ()
>
> Oh, so this is happening during index entry creation? (The reference to
> heap_modifytuple is misleading, but in a debug-symbol-free backend it's
> not so surprising.)
>
> This suddenly looks a whole lot like a known bug:
> http://archives.postgresql.org/pgsql-hackers/2005-11/msg01016.php
>
> Which version did you say you were using exactly? That bug is fixed
> in 8.1.1 ...
>
> regards, tom lane
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

--
"The best way to predict the future is to invent it."
- XEROX PARC slogan, circa 1978