From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Vincent Lachenal <vincent.lachenal@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Subject: Re: BUG #14897: Segfault on statitics SQL request
Date: Sat, 11 Nov 2017 12:54:29 -0500
Message-ID: <4612.1510422869@sss.pgh.pa.us> (raw)
In-Reply-To: <20171111174512.ikd3zrx2i5ssxpww@alap3.anarazel.de>
References: <CAA2tJ7p72wbuHEzOA_g2V4YcmeDPHYKggenTR4dXG=kSpCiO8Q@mail.gmail.com>
<14075.1510352167@sss.pgh.pa.us>
<CA+q6zcXe9aV5NV88u9Y=vMp+=fP7QOXgTyFQhzuvmCvTBvb_kQ@mail.gmail.com>
<17617.1510355215@sss.pgh.pa.us>
<CAB7nPqR7mWvtnALZF93oez_v03NFCJ8dXP9CNicaUDv3KjDbYw@mail.gmail.com>
<CA+q6zcVE2FQ9irhENEy=2WjRWgV2hyzfYyOXFs36w=hsk4faBw@mail.gmail.com>
<644.1510418216@sss.pgh.pa.us>
<CA+q6zcWwjTNgA6JiqQ5L-oAFF5X9ONtKSAvznte63A7Zb7zaww@mail.gmail.com>
<20171111171620.td6vtnmijcloj6k5@alap3.anarazel.de>
<3914.1510422100@sss.pgh.pa.us>
<20171111174512.ikd3zrx2i5ssxpww@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, 9erthalion6@gmail.com, michael.paquier@gmail.com, vincent.lachenal@gmail.com
Subject: Re: BUG #14897: Segfault on statitics SQL request
In-Reply-To: <4612.1510422869@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox