From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(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: [BUGS] BUG #14897: Segfault on statitics SQL request |
Date: | 2017-11-14 03:31:23 |
Message-ID: | 17615.1510630283@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I wrote:
> So what I am now thinking is that the only practical answer is to stop
> gcc from believing that it is safe to use 16-aligned instructions on
> int128's. (Some reading on the net suggests that the actual performance
> penalty for that is minimal anyway on modern Intel chips.)
Concretely, the attached patch fixes it for me. I've verified by
examining the assembly code that this stops gcc from using movdqa or
movaps in numeric.c, except for one place where it apparently can
prove that it's dealing with a sufficiently-aligned local variable.
As I said before, I don't like moving the int128 typedefs into a section
where they don't belong, but that's just cosmetic --- this is good enough
for testing.
BTW, for me, gcc only seems to want to generate 16-aligned instructions
in functions used for parallel aggregation. That may explain why we've
not seen a report before: the vulnerable code exists in 9.6, but it's not
used by default, since parallelization isn't on by default.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
int128-hack.patch | text/x-diff | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-11-14 05:20:25 | Re: [BUGS] BUG #14897: Segfault on statitics SQL request |
Previous Message | xkevin.hk | 2017-11-14 02:07:01 | BUG #14905: can't restart successfully because of existed pid file of httpd |