From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: epoll_wait returning EFAULT on Linux 3.2.78 |
Date: | 2016-06-02 17:41:00 |
Message-ID: | CAM-w4HMYU81JXHjqPuvTsc+sJpF+h4SDwkD8=51r13hxgUApzQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 2, 2016 at 6:35 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Want me to polish that up and push, or do you want to go back and forth
> and push yourself?
I'm happy to check if my bits still work if it's not too much hassle
to go back and forth.
> They should be *after* the multiplications. If arrays of structs are
> internally misaligned there's nothing we can do.
Well there's not *nothing* we can do. I thought I we were going to
have to go back and do manual offset calculations to get that right.
But with the u64_t element that's probably not necessary. It's a bit
scary having that be the only thing protecting it but then again it's
probably exactly why it's there. Given how much of a pain doing manual
offset calculations I'm happy to go along and say it's not worth
bothering.
Should the maxaligns be there for the non-epoll cases? I tossed them
in without paying much attention. I really have no idea if they're
needed on Windows or not for example.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-06-02 17:46:56 | Re: epoll_wait returning EFAULT on Linux 3.2.78 |
Previous Message | Andres Freund | 2016-06-02 17:35:15 | Re: epoll_wait returning EFAULT on Linux 3.2.78 |