Re: kqueue

From: Marko Tiikkaja <marko(at)joh(dot)to>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: kqueue
Date: 2016-09-06 22:32:59
Message-ID: 45539ad5-28ff-169f-1055-a8e269c1bdf9@joh.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016-06-03 01:45, Thomas Munro wrote:
> On Fri, Jun 3, 2016 at 4:02 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>> Tom Lane wrote:
>>> Andres Freund <andres(at)anarazel(dot)de> writes:
>>>>> pg_strtoi?
>>>
>>>> I think that's what Thomas did upthread. Are you taking this one then?
>>>
>>> I'd go with just "strtoint". We have "strtoint64" elsewhere.
>>
>> For closure of this subthread: this rename was committed by Tom as
>> 0ab3595e5bb5.
>
> Thanks. And here is a new version of the kqueue patch. The previous
> version doesn't apply on top of recent commit
> a3b30763cc8686f5b4cd121ef0bf510c1533ac22, which sprinkled some
> MAXALIGN macros nearby. I've now done the same thing with the kevent
> struct because it's cheap, uniform with the other cases and could
> matter on some platforms for the same reason.

I've tested and reviewed this, and it looks good to me, other than this
part:

+ /*
+ * kevent guarantees that the change list has been processed in the
EINTR
+ * case. Here we are only applying a change list so EINTR counts as
+ * success.
+ */

this doesn't seem to be guaranteed on old versions of FreeBSD or any
other BSD flavors, so I don't think it's a good idea to bake the
assumption into this code. Or what do you think?

.m

In response to

  • Re: kqueue at 2016-06-02 23:45:10 from Thomas Munro

Responses

  • Re: kqueue at 2016-09-10 01:29:00 from Thomas Munro

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2016-09-06 22:47:54 Re: Parallel tuplesort (for parallel B-Tree index creation)
Previous Message Peter Geoghegan 2016-09-06 21:46:41 Re: Parallel tuplesort (for parallel B-Tree index creation)