Re: Postgresql Segfault in 8.1
От | Benjamin Smith |
---|---|
Тема | Re: Postgresql Segfault in 8.1 |
Дата | |
Msg-id | 200601251317.43507.lists@benjamindsmith.com обсуждение исходный текст |
Ответ на | Re: Postgresql Segfault in 8.1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Postgresql Segfault in 8.1
Re: Postgresql Segfault in 8.1 |
Список | pgsql-general |
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@benjamindsmith.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
В списке pgsql-general по дате отправления: