| 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-12 17:43:02 |
| Message-ID: | 3379.1510508582@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
I wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> 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.
Actually, independently of which way we do that, it seems like we can't
easily hide this inside a palloc wrapper. If we palloc some extra space
and then adjust the return value to be 16-aligned, what happens when the
caller tries to pfree the block?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | gregburek | 2017-11-12 22:28:11 | BUG #14901: Canceled queries missing from pg_stat_statements |
| Previous Message | Tom Lane | 2017-11-12 17:39:12 | Re: BUG #14897: Segfault on statitics SQL request |