From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Vincent Lachenal <vincent(dot)lachenal(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14897: Segfault on statitics SQL request |
Date: | 2017-11-11 17:54:29 |
Message-ID: | 4612.1510422869@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 2017-11-11 12:41:40 -0500, Tom Lane wrote:
>> Yeah, changing MAXALIGN is out of the question. I'm thinking about
>> another flag bit for MemoryContextAllocExtended. Do we need to think
>> about other use-cases besides int128? Should we just force 16-byte
>> alignment on all architectures, or does it need to be platform-specific?
> I'm not sure we want to
> a) Rely on one alignment being enough for everybody.
> b) Additionally burden already hot code paths with a growing number of
> alignment flag tests, and the necessary math.
Well, (a) we could have more flag bits later if there are other use-cases
that require even stricter alignment, and (b) I do not believe that
MemoryContextAllocExtended is a hot code path at present; there are not
enough call sites.
> How about a MemoryContextAllocAligned(context, size, alignto, flags)
> that passes on most flags but adds the necessary overhead to size, and
> padds the result appropriately?
This'd result in hard-wiring the alignment requirement at call sites,
which I think might not be a great idea. For example, one plausible
future use-case is "align on cacheline boundaries". I think that would
be better served by a flag like MCXT_ALLOC_ALIGN_CACHELINE than by
having the callers demand a specific numeric alignment value --- it'd
be a lot easier to make the alignment match actual hardware requirements
if it were being inserted at one specific place.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-11-11 18:11:45 | Re: BUG #14897: Segfault on statitics SQL request |
Previous Message | Andres Freund | 2017-11-11 17:45:12 | Re: BUG #14897: Segfault on statitics SQL request |