> On 24 Jun 2016, at 01:53, Andres Freund <andres@anarazel.de> wrote:
>=20
> On 2016-06-22 11:45:16 -0400, Tom Lane wrote:
>> petrum@gmail.com writes:
>>> File: =
postgresql-9.4.4/src/backend/replication/logical/reorderbuffer.c
>>> Function: ReorderBufferInterTXNInit
>>> Line: 870
>>=20
>>> The line is
>>> if (txn->nentries !=3D txn->nentries_mem)
>>> But shouldn't be there cur_txn instead of txn?
>>=20
>> Actually, the function is ReorderBufferIterTXNInit, and in HEAD this
>> is line 963, but yeah that looks pretty broken. Andres, do you
>> concur?
>=20
> Ugh, yes, that looks broken. In a way that can very likely lead to =
wrong
> data being returned :(. I assume an empty toplevel transaction +
> subtransactions with spilled-to-disk contents will be bad.
>=20
>=20
>> Or maybe the logic needs to be different for subtransactions?
>>=20
>>> I do not know exactly the semantics of the code because I detected =
the
>>> problem with a CodeSonar prototype plugin.
>>=20
>> Seems like a cool tool.
>=20
> Indeed. What heuristic lead to detecting this? I can think of some, =
but
> they all owuld have significant false-positive rates.
Thank you :). I cannot disclose this. The tool I develop is a CodeSonar =
(www.grammatech.com)
plugin. It is work in progress still under refinement.