| From: | "petrum(at)gmail(dot)com" <petrum(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #14208: Inconsistent code modification - 3 |
| Date: | 2016-06-25 04:57:17 |
| Message-ID: | 5778942A-7E79-4621-A8D0-BA479EFCB4F7@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> On 24 Jun 2016, at 01:53, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> 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.
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mr Mashele Comfort | 2016-06-25 14:46:46 | Database Creation |
| Previous Message | Alvaro Herrera | 2016-06-24 22:59:30 | Re: BUG #14195: "MultiXactId XXXXXX has not been created yet -- apparent wraparound" after upgrade from 9.2 |