* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> root@simply.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 back=
ends.
> > Backtraces of all coredumps look similar:
> > (gdb) bt
> > #0 0x000000000066bf9b in BackendIdGetTransactionIds (backendID=3D<value
> > optimized out>, xid=3D0x7f2a1b714798, xmin=3D0x7f2a1b71479c) at sinvala=
dt.c:426
> > #1 0x00000000006287f4 in pgstat_read_current_status () at pgstat.c:2871
> > #2 0x0000000000628879 in pgstat_fetch_stat_numbackends () at pgstat.c:=
2342
>=20
> 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,=20
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.
These are likely being run by a monitoring system (eg: check_postgres
=66rom Nagios).
Thanks!
Stephen