* Vladimir Borodin (root@simply.name) wrote:
> > 30 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2015 =D0=B3., =D0=B2 19:44, Stephen F=
rost <sfrost@snowman.net> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0=
):
> > * Tom Lane (tgl@sss.pgh.pa.us <mailto: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 ba=
ckends.
> >>> Backtraces of all coredumps look similar:
> >>> (gdb) bt
> >>> #0 0x000000000066bf9b in BackendIdGetTransactionIds (backendID=3D<va=
lue
> >>> optimized out>, xid=3D0x7f2a1b714798, xmin=3D0x7f2a1b71479c) at sinva=
ladt.c:426
> >>> #1 0x00000000006287f4 in pgstat_read_current_status () at pgstat.c:2=
871
> >>> #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_stat=
us
> >> saw the backend as active and where we're inspecting its sinval entry.
> >=20
> > 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.
>=20
> I suppose, pg_stat_replication should not be asked too. We have already d=
one that on most critical databases but it is hard to be blind :(
Ah, yes, not sure where I dropped that; it was in my initial list but
didn't make it into the final email.
I would expect a fix to be included in the next point release, hopefully
released in the next couple of months.
Thanks!
Stephen