> 30 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2015 =D0=B3., =D0=B2 19:33, Tom Lane =
<tgl@sss.pgh.pa.us> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):
>=20
> 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 =
backends.
>> Backtraces of all coredumps look similar:
>> (gdb) bt
>> #0 0x000000000066bf9b in BackendIdGetTransactionIds =
(backendID=3D<value
>> optimized out>, xid=3D0x7f2a1b714798, xmin=3D0x7f2a1b71479c) 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
>=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.
I=E2=80=99ve also tried to revert dd1a3bcc where this function appeared =
but couldn=E2=80=99t do it :( If you would be able to make a build =
without this commit (if it is easier than fix it in right way), I could =
install it on several production hosts to test it.
>=20
> regards, tom lane
--
May the force be with you=E2=80=A6
https://simply.name