Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double free or corruption (!pre
От | Vitaly V. Voronov |
---|---|
Тема | Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double free or corruption (!pre |
Дата | |
Msg-id | 3343581523000521@web56o.yandex.ru обсуждение исходный текст |
Ответ на | Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole[local] SELECT: double free or corruption (!pre (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole[local] SELECT: double free or corruption (!pre
|
Список | pgsql-bugs |
Hello, 06.04.2018, 02:18, "Peter Geoghegan" <pg@bowt.ie>: > On Thu, Apr 5, 2018 at 3:39 PM, PG Bug reporting form > <noreply@postgresql.org> wrote: >> We have problem at our Master server (second time). >> From first time, we update CentOS to latest version (6.9) >> But today we have such bug: >> *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double >> free or corruption (!prev): 0x00000000022529e0 *** > > Can you get a full stack trace from a coredump? > > https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD > > It would be particularly helpful if you were able to collect a > coredump, and run "p *debug_query_string" from GDB. > > It would also be nice to be able to get the query string from some > other source, such as the server log. Perhaps it can be correlated to > something? Sorry. I can't do this. Because, 1s - this is production and 2nd - it had been initialized as replica. We use 2 server, and this server (with error) now initialized as secondary. We use pgpool for switching servers. And i posted full log from Postgres logs. All other logs is clear. > >> ======= Backtrace: ========= >> /lib64/libc.so.6(+0x75dee)[0x7f6b19433dee] >> /lib64/libc.so.6(+0x78c80)[0x7f6b19436c80] >> postgres: postgres smsconsole [local] >> SELECT(tuplestore_end+0x17)[0x808887] >> postgres: postgres smsconsole [local] >> SELECT(ExecEndFunctionScan+0x75)[0x5e94e5] >> postgres: postgres smsconsole [local] >> SELECT(standard_ExecutorEnd+0x2e)[0x5cbaae] > > Offhand, I suspect that this could be a bug that is analogous to the > one just fixed within tuplesort, by > c2d4eb1b1fa252fd8c407e1519308017a18afed1. There is a fairly long > history of these kinds of bugs, including one or two in tuplestore > that I can recall from memory. We have zabbix monitoring, which actively using pg_stat_* and pg_buffercache. Can this cause such problem? Can you answer, when such changes will be released in production? > > -- > Peter Geoghegan Thanks for you answers!
В списке pgsql-bugs по дате отправления: