Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication
Дата
Msg-id CA+TgmoZpTW_A3--Mno=oFdc84DEQaDqQ0gsWmnt7xPifPWwRTw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication  (Dave Cramer <davecramer@gmail.com>)
Ответы Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication  (Craig Ringer <craig.ringer@2ndquadrant.com>)
Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication  (Jorge Solórzano <jorsol@gmail.com>)
Список pgsql-jdbc
On Thu, Jan 19, 2017 at 12:09 PM, Dave Cramer <davecramer@gmail.com> wrote:
> I would have expected more, but this is what I have
>
>  bt full
> #0  InitPredicateLocks () at predicate.c:1250
>         i = <optimized out>
>         info = {num_partitions = 1, ssize = 140731424825288, dsize = 1,
>           max_dsize = 0, ffactor = 140731424836952, keysize =
> 140356326474085,
>           entrysize = 140728909791233, hash = 0x7ffe96960d58,
>           match = 0x16da2d1, keycopy = 0x7ffe96960d58, alloc = 0x1703af0,
>           hcxt = 0x16da2d0, hctl = 0x0}
>         max_table_size = 117899280
>         requestSize = <optimized out>
>         found = 0 '\000'

I would say that's not a valid stack trace.  There hasn't been a
change made to that file since October of last year, and the crash is
apparently recent; also, line 1250 in that file doesn't look like
something that can crash.  I would guess that you're using an
executable which doesn't match the core dump, or perhaps that you
don't have complete debug symbols.  Building with -O0 might help.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication