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!