Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION
Date
Msg-id 18587.1456770929@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION  (Andres Freund <andres@anarazel.de>)
List pgsql-bugs
Andres Freund <andres@anarazel.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

pgsql-bugs by date:

Previous
From: Сергей Кочетков
Date:
Subject: Prepared statements
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #13894: MANPATH in documentation - wrong path