| 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 19:31:47 |
| Message-ID: | 9597.1510428707@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:54:29 -0500, Tom Lane wrote:
>> 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.
> Specifying MCXT_ALLOC_ALIGN_CACHELINE rather than CACHELINE_ALIGNMENT
> doesn't seem to make it meaningfully harder to adjust. Or are you
> thinking of probing the hardware?
Yeah, the latter. The two approaches seem pretty much equivalent if
you're assuming compile-time decisions, but if we ever wanted a run-
time decision, I think having a flag bit that's interpreted inside
MemoryContextAllocExtended would be easier to deal with.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | neil | 2017-11-12 03:16:21 | BUG #14900: MView not null constraint |
| Previous Message | Andres Freund | 2017-11-11 18:11:45 | Re: BUG #14897: Segfault on statitics SQL request |