Greg Stark writes:
> Ok. I added a comment and also fixed a small typo.
Looks sane to me, though I might reduce the comment to something like
"MAXALIGN all the subsidiary arrays, to avoid interdependencies of the
alignment requirements of their component types."
regards,
Hi,
On 2016-06-02 19:15:07 +0100, Greg Stark wrote:
> Ok. I added a comment and also fixed a small typo.
> diff --git a/src/backend/storage/ipc/latch.c b/src/backend/storage/ipc/latch.c
> index 3fbe0e5..a96fb7b 100644
> --- a/src/backend/storage/ipc/latch.c
> +++ b/src/backend/storage/ipc/latch.c
Ok. I added a comment and also fixed a small typo.
diff --git a/src/backend/storage/ipc/latch.c b/src/backend/storage/ipc/latch.c
index 3fbe0e5..a96fb7b 100644
--- a/src/backend/storage/ipc/latch.c
+++ b/src/backend/storage/ipc/latch.c
@@ -485,35 +485,40 @@ CreateWaitEventSet(MemoryContext context,
Andres Freund writes:
> On 2016-06-02 18:41:00 +0100, Greg Stark wrote:
>> 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.
> The kernel accesses the elements as an array. If the array stride (by
> virtue of
On 2016-06-02 18:41:00 +0100, Greg Stark wrote:
> On Thu, Jun 2, 2016 at 6:35 PM, Andres Freund 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
On Thu, Jun 2, 2016 at 6:35 PM, Andres Freund 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
On 2016-06-02 18:15:54 +0100, Greg Stark wrote:
> I just threw maxalign everywhere but I was going to comment that we
> might need to put a double in for the subsequent struct elements to
> end up aligned as well.
Hm. Shouldn't be needed if you MAXALIGN the sz computation, because
that'll mean eac
On 2016-06-02 13:24:38 -0400, Tom Lane wrote:
> Andres Freund writes:
> > That makes sense independent of 32 vs. 64 system. Part of the relevant
> > struct probably require 8 byte alignment:
>
> >typedef union epoll_data {
> >void*ptr;
> >int f
Andres Freund writes:
> That makes sense independent of 32 vs. 64 system. Part of the relevant
> struct probably require 8 byte alignment:
>typedef union epoll_data {
>void*ptr;
>int fd;
>uint32_t u32;
>uint64_t
On Thu, Jun 2, 2016 at 6:04 PM, Andres Freund wrote:
> Greg, are you writing & testing a patch? Or should I write something for
> you to test?
I'm running the regression tests now. They look like they're passing.
I just threw maxalign everywhere but I was going to comment that we
might need to p
Hi,
On 2016-06-02 17:50:20 +0100, Greg Stark wrote:
> So FYI, it does look like Postgres built in 32-bit mode, at least
> pointers are 32 bits. But I think maxalign might still be enough due
> to doubles being 64 bits.
That makes sense independent of 32 vs. 64 system. Part of the relevant
struct
Greg Stark writes:
> So FYI, it does look like Postgres built in 32-bit mode, at least
> pointers are 32 bits. But I think maxalign might still be enough due
> to doubles being 64 bits.
OK, let's just maxalign all the components of the WaitEventSet struct
and call it good, at least till we find o
So FYI, it does look like Postgres built in 32-bit mode, at least
pointers are 32 bits. But I think maxalign might still be enough due
to doubles being 64 bits.
checking whether long int is 64 bits... no
checking whether long long int is 64 bits... yes
checking snprintf length modifier for long lo
Greg Stark writes:
> On Thu, Jun 2, 2016 at 3:50 PM, Tom Lane wrote:
>> I notice that CreateWaitEventSet() is being remarkably cavalier
>> about alignment requirements; maybe it ought to make some effort
>> to ensure that epoll_ret_events is maxaligned.
> That makes a certain amount of sense as
On Thu, Jun 2, 2016 at 3:50 PM, Tom Lane wrote:
> The man page for epoll_wait suggests that that implies a bad pointer
> value for the events array. You're showing
> epoll_ret_events = 0x9c0ad4
> which is not obviously bad, but it's also only 4-byte aligned.
> I notice that CreateWaitEven
Greg Stark writes:
> What I'm seeing is that every call to epoll_wait() raises EFAULT.
The man page for epoll_wait suggests that that implies a bad pointer
value for the events array. You're showing
epoll_ret_events = 0x9c0ad4
which is not obviously bad, but it's also only 4-byte aligned
Hi,
On 2016-06-02 15:31:15 +0100, Greg Stark wrote:
> What I'm seeing is that every call to epoll_wait() raises EFAULT. I
> don't see anything wrong with the arguments to epoll_wait so unless
> there was some earlier bogus argument to epoll_ctl or something this
> looks like some kind of kernel or
I was just trying out a new (well, new to me...) machine here. It
happens that the version of Linux installed is 3.2.78. Apparently the
current version on this branch is 3.2.80 released a couple months ago
and I don't see any relevant changes in .79 or .80 so I think this is
actually likely to be t
18 matches
Mail list logo
