From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | petrum(at)gmail(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14208: Inconsistent code modification - 3 |
Date: | 2016-06-23 22:53:01 |
Message-ID: | 20160623225301.4v7heuiyvkfwi5ev@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2016-06-22 11:45:16 -0400, Tom Lane wrote:
> petrum(at)gmail(dot)com writes:
> > File: postgresql-9.4.4/src/backend/replication/logical/reorderbuffer.c
> > Function: ReorderBufferInterTXNInit
> > Line: 870
>
> > The line is
> > if (txn->nentries != txn->nentries_mem)
> > But shouldn't be there cur_txn instead of txn?
>
> Actually, the function is ReorderBufferIterTXNInit, and in HEAD this
> is line 963, but yeah that looks pretty broken. Andres, do you
> concur?
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.
> Or maybe the logic needs to be different for subtransactions?
>
> > I do not know exactly the semantics of the code because I detected the
> > problem with a CodeSonar prototype plugin.
>
> Seems like a cool tool.
Indeed. What heuristic lead to detecting this? I can think of some, but
they all owuld have significant false-positive rates.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-06-23 23:08:57 | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column |
Previous Message | jie.long | 2016-06-23 22:07:10 | BUG #14212: DB crash: system logger process was terminated by exception 0xFFFFFFFFwith exception 0xFFFFFFFF |