Re: [HACKERS] OK, so culicidae is *still* broken - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] OK, so culicidae is *still* broken
Date
Msg-id 15162.1493129233@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] OK, so culicidae is *still* broken  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [HACKERS] OK, so culicidae is *still* broken  (Craig Ringer <craig@2ndquadrant.com>)
Re: [HACKERS] OK, so culicidae is *still* broken  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Craig Ringer <craig@2ndquadrant.com> writes:
> On 25 Apr. 2017 13:37, "Heikki Linnakangas" <hlinnaka@iki.fi> wrote:
>> For some data shared memory structures, that store no pointers, we wouldn't
>> need to insist that they are mapped to the same address in every backend,
>> though. In particular, shared_buffers. It wouldn't eliminate the problem,
>> though, only make it less likely, so we'd still need to retry when it does
>> happen.

> Good point. Simply splitting out shared_buffers into a moveable segment
> would make a massive difference. Much less chance of losing the dice roll
> for mapping the fixed segment.

> Should look at what else could be made cheaply relocatable too.

I don't think it's worth spending any effort on.  We need the retry
code anyway, and making it near impossible to hit that would only mean
that it's very poorly tested.  The results upthread say that it isn't
going to be hit often enough to be a performance problem, so why worry?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Abbas Butt
Date:
Subject: [HACKERS] PG_TRY & PG_CATCH in FDW development
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] PG 10 release notes