Re: PATCH: pgbench - option to build using ppoll() for largerconnection counts - Mailing list pgsql-hackers

From Rady, Doug
Subject Re: PATCH: pgbench - option to build using ppoll() for largerconnection counts
Date
Msg-id 654A1247-8E1E-4E9C-937D-9119B1731FF2@amazon.com
Whole thread Raw
In response to Re: PATCH: pgbench - option to build using ppoll() for largerconnection counts  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: PATCH: pgbench - option to build using ppoll() for largerconnection counts
Re: PATCH: pgbench - option to build using ppoll() for largerconnection counts
List pgsql-hackers
On 1/26/18, 15:00, "Fabien COELHO" <coelho@cri.ensmp.fr> wrote:
        Hello Doug,

Hello Fabien,
    
    Patch applies, compiles, tests ok.
    
    >    > [...] Replaced USE_PPOLL with HAVE_PPOLL as having both seems redundant.
    >
    >    I'm okay with that. I'm wondering whether there should be a way to force
    >    using one or the other when both are available. Not sure.
    >
    > Added option to force use of select(2) via:  -DUSE_SELECT
    
    USE_SELECT could mean something somewhere. Maybe use something more 
    specific like PGBENCH_USE_SELECT? Having this macro available simplifies 
    testing.

Changed to PGBENCH_USE_SELECT
    
    I'm not sure why you do the following trick, could you explain?
       +#undef USE_SELECT
       +#define USE_SELECT

This was due to compiler complaint about USE_SELECT being redefined.
Have replaced that "trick" with a new #define POLL_USING_SELECT which is used elsewhere in pgbench instead.
    
    In the select implementation you do:
    
      return (socket_set *) pg_malloc0(sizeof(socket_set) * MAXCLIENTS);
    
    but ISTM that socket_set is already an fd_set which represents a set of 
    clients, so allocating a number of it is needed. The initial 
    implementation just does "fs_set input_mask", whetever the number of 
    clients, and it works fine.

Ugh. Yes, for socket() only one (1) fd_set is needed.
Fixed.
    
    -- 
    Fabien.

Thank you, again!!
doug
    




Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Documentation of pgcrypto AES key sizes
Next
From: Ivan Novick
Date:
Subject: Re: Built-in connection pooling