Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(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-29 18:35:29
Message-ID: 18587.1456770929@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2016-02-25 12:20:06 -0500, Tom Lane wrote:
>> Seems like we can either (1) get rid of that memmove in favor of
>> a handwritten loop, or (2) give up on unlocked access to the
>> pgprocnos array. Which performance hit would you rather take?

> I think 1), while it'll be noticeable, it's probably going to degrade
> much more gracefully.

> I think we additionally also should add a security check to
> MinimumActiveBackends that prevents a pgprocno above the max number of
> backends to be seen as valid.

So we have three proposals on the table:
* volatile-ize arrayP
* range-check the pgprocno after we fetch it
* replace memmove(s) with int-at-a-time move loop(s)

I wonder whether we couldn't leave the memmoves alone if we do the other
two things. It would mean that MinimumActiveBackends would sometimes
miss examining some backends, but that's going to happen anyway given
its use of unlocked access.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2016-02-29 20:55:29 Re: BUG #13894: MANPATH in documentation - wrong path
Previous Message Euler Taveira 2016-02-29 13:39:07 Re: BUG #13993: Temp sequence does not seem to be properly deleted