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
Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication |
Список | 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 по дате отправления: