Re: [BUGS] BUG #14897: Segfault on statitics SQL request
От | Tom Lane |
---|---|
Тема | Re: [BUGS] BUG #14897: Segfault on statitics SQL request |
Дата | |
Msg-id | 4612.1510422869@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14897: Segfault on statitics SQL request (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [BUGS] BUG #14897: Segfault on statitics SQL request
|
Список | pgsql-bugs |
Andres Freund <andres@anarazel.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: