Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION

From: "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, chris(dot)tessels(at)inergy(dot)nl, Pg Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION
Date: 2016-02-25 15:52:53
Message-ID: CACACo5SKaGwErY5NLcf9oSomdDZXo8rgRM-OFGA7oR+G6U+WGA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Feb 25, 2016 at 3:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> writes:
> > On Wed, Feb 24, 2016 at 10:52 PM, Andres Freund <andres(at)anarazel(dot)de>
> wrote:
> > At the very least ISTM that we have to make pgprocno volatile (or use a
> >> memory barrier - but we don't have sufficient support for those in the
> >> older branches), and move the PGPROC/PGXACT lookups after the == -1
> >> check.
>
> > Use of volatile doesn't change the resulting code dramatically for me.
>
> Marking pgprocno volatile is silly. What *is* missing is this:
>
> - ProcArrayStruct *arrayP = procArray;
> + volatile ProcArrayStruct *arrayP = procArray;
>
> which corresponds directly to what the problem is: the storage arrayP
> is pointing at may change asynchronously.
>

Right, this makes a lot more sense.

--
Alex

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Pavel Stehule 2016-02-25 16:28:19 Re: Query-Sending mail from PostgresSQL
Previous Message el_froggy 2016-02-25 15:20:19 BUG #13991: Installing results in Failed to load sql modules into the database cluster