Re: BUG #12918: Segfault in BackendIdGetTransactionIds

> 30 марта 2015 г., в 19:44, Stephen Frost <sfrost(at)snowman(dot)net> написал(а):
>
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>) wrote:
>> root(at)simply(dot)name writes:
>>> After upgrading from 9.3.6 to 9.4.1 (both installed from packages on
>>> yum.postgresql.org) we have started getting segfaults of different backends.
>>> Backtraces of all coredumps look similar:
>>> (gdb) bt
>>> #0 0x000000000066bf9b in BackendIdGetTransactionIds (backendID=<value
>>> optimized out>, xid=0x7f2a1b714798, xmin=0x7f2a1b71479c) at sinvaladt.c:426
>>> #1 0x00000000006287f4 in pgstat_read_current_status () at pgstat.c:2871
>>> #2 0x0000000000628879 in pgstat_fetch_stat_numbackends () at pgstat.c:2342
>>
>> Hmm ... looks to me like BackendIdGetTransactionIds is simply busted.
>> It supposes that there are no inactive entries in the sinval array
>> within the range 0 .. lastBackend. But there can be, in which case
>> dereferencing stateP->proc crashes. The reason it's hard to reproduce
>> is the relatively narrow window between where pgstat_read_current_status
>> saw the backend as active and where we're inspecting its sinval entry.
>
> As an immediate short-term workaround, from what I can tell,
> disabling calls to pg_stat_activity, and pg_stat_database (views), and
> pg_stat_get_activity, pg_stat_get_backend_idset, and
> pg_stat_get_db_numbackends (functions) should prevent triggering this
> bug.

I suppose, pg_stat_replication should not be asked too. We have already done that on most critical databases but it is hard to be blind :(

>
> These are likely being run by a monitoring system (eg: check_postgres
> from Nagios).
>
> Thanks!
>
> Stephen

--
May the force be with you…
https://simply.name