Обсуждение: postmaster listening on specified addresses

Hello,

I was wondering if there's a correct method for running postmaster with the
option of listening on a select group of addresses.  Does postmaster accept
multiple "-h hostname" options on the command-line, or alternatively a
comma-separated list of hostnames or addresses?  What if you have a server with
multiple network interfaces and addresses assigned to each, and you only want
postmaster to listen on a specific subset of those addresses in addition to
localhost?  Does anyone know if there a supported method for doing this?

The documentation for the "-h" option only states: "Specifies the TCP/IP host
name or address on which the postmaster is to listen for connections from client
applications. Defaults to listening on all configured addresses (including
localhost)."  Clearly the server is capable of listening on mutliple addresses
since the default is all of them, but the "-h" option is described only for use
with a single address.

Thanks,

Brian Carp

Administrator <admin@photoresearchers.com> writes:

> Hello,
>
> I was wondering if there's a correct method for running postmaster
> with the option of listening on a select group of addresses.  Does
> postmaster accept multiple "-h hostname" options on the command-line,
> or alternatively a comma-separated list of hostnames or addresses?
> What if you have a server with multiple network interfaces and
> addresses assigned to each, and you only want postmaster to listen on
> a specific subset of those addresses in addition to localhost?  Does
> anyone know if there a supported method for doing this?

It would require changes to the existing code (see below).

> The documentation for the "-h" option only states: "Specifies the
> TCP/IP host name or address on which the postmaster is to listen for
> connections from client applications. Defaults to listening on all
> configured addresses (including localhost)."  Clearly the server is
> capable of listening on mutliple addresses since the default is all of
> them, but the "-h" option is described only for use with a single
> address.

Actually, in the sockets API to listen on "all configured addresses"
you specify the "wildcard" address (0.0.0.0).  There is no call to
"listen on this list of addresses".  What you are looking for could be
done, but it would require multiple listening sockets, one for each
address, which (as far as I know) the code doesn't currently do.

-Doug

On Fri, Jan 14, 2005 at 03:28:24PM -0500, Administrator wrote:

> I was wondering if there's a correct method for running postmaster with the
> option of listening on a select group of addresses.

PostgreSQL 8.0 will allow this -- it'll replace the virtual_host
configuration variable with listen_addresses, and postmaster's -h
option will be equivalent to listen_addresses.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

Hi,

I'm writing some code for asychronous command processing and I experience
the following problem. Everything seems to be OK (by following the
documentation) until I call PQisBusy(). While PQconsumeInput() returns 1,
PQisBusy() always returns 1! This is the code:

 -------------------------------------------------------------------------
....
// conn is the connection already established in a nonblocking way
//(this is OK, I checked it with sychronous command processing)

    PQsetnonblocking(conn,1);

       //A simple query for now...
    sql = "select * from t1";

    if (PQsendQuery(conn,sql)!=1)
       elog(ERROR,"Something went wrong with PQsendQuery....");

    PQflush(conn);

    sock = PQsocket(conn);

    if (sock < 0)
        break;

    FD_ZERO(&input_mask);
    FD_SET(sock, &input_mask);

    if (select(sock + 1, &input_mask, NULL, NULL,NULL) < 0)
        elog(ERROR,"Nothing comes to my socket!");


       if (PQconsumeInput(conn)!=1) elog(ERROR,"Error in consume...");
    else
    {
        elog(INFO,"OK with PQconsumeInput");

               //Will use a cursor and 'while' later when this
               //will have been fixed...
        if (!PQisBusy(conn))
        {
             res=PQgetResult(conn);
         }
        else elog(INFO,"It is too busy to give me the results!");
       }
...
 -------------------------------------------------------------------------

If I discard PQisBusy the results are retreived without problems.

This code is used inside a SRF that is intended to return tuples from remote
dbs (as in dblink). For the time being I query local tables.
I use v7.4.2.

Is this something too obvious to see it :-) ? Is it something with
nonblocking connection establishment? Any suggestions?

Thanks in advance,
Ntinos Katsaros

ntinos@aueb.gr writes:
>        if (PQconsumeInput(conn)!=1) elog(ERROR,"Error in consume...");
>     else
>     {
>         elog(INFO,"OK with PQconsumeInput");

>                //Will use a cursor and 'while' later when this
>                //will have been fixed...
>         if (!PQisBusy(conn))
>         {
>              res=PQgetResult(conn);
>          }
>         else elog(INFO,"It is too busy to give me the results!");
>        }

PQconsumeInput has to be part of the loop.  PQisBusy doesn't change any
state, it just tells you whether PQconsumeInput has collected a complete
query result yet.

            regards, tom lane

If understand correctly what you are saying, the right code for this thing
is:

PQconsumeInput(conn);        //Try to collect the results
while (PQisBusy(conn))       // while not ready ...
    PQconsumeInput(conn); //...retry

res=PQgetResult(conn);       // Now get the results

I tried this and it worked. However, the problem now is that it is slow
(surely slower than using blocking commands).
If the code above is right (?), why is that?

Thanks for your response,
Ntinos Katsaros

Tom Lane writes:

> ntinos@aueb.gr writes:
>>        if (PQconsumeInput(conn)!=1) elog(ERROR,"Error in consume...");
>>     else
>>     {
>>         elog(INFO,"OK with PQconsumeInput");
>
>>                //Will use a cursor and 'while' later when this
>>                //will have been fixed...
>>         if (!PQisBusy(conn))
>>         {
>>              res=PQgetResult(conn);
>>          }
>>         else elog(INFO,"It is too busy to give me the results!");
>>        }
>
> PQconsumeInput has to be part of the loop.  PQisBusy doesn't change any
> state, it just tells you whether PQconsumeInput has collected a complete
> query result yet.
>
>             regards, tom lane

On Sat, Jan 15, 2005 at 09:50:35PM +0200, ntinos@aueb.gr wrote:
> If understand correctly what you are saying, the right code for this thing
> is:
>
> PQconsumeInput(conn);        //Try to collect the results
> while (PQisBusy(conn))       // while not ready ...
>     PQconsumeInput(conn); //...retry
>
> res=PQgetResult(conn);       // Now get the results
>
> I tried this and it worked. However, the problem now is that it is slow
> (surely slower than using blocking commands).
> If the code above is right (?), why is that?

The purpose of non-blocking commands is so you can do something else
useful in the meantime. The above is probably slower because you're
using all your CPU time spinning in a loop.

I belive if you're waiting in an event loop, you can use PQsocket() to
return the fd to use in select. Or if you're doing other work, do that
while you're waiting and check isBusy when you have time...

Hope this helps,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Martijn van Oosterhout writes:

> On Sat, Jan 15, 2005 at 09:50:35PM +0200, ntinos@aueb.gr wrote:
>> PQconsumeInput(conn);        //Try to collect the results
>> while (PQisBusy(conn))       // while not ready ...
>>     PQconsumeInput(conn); //...retry
>>
>> res=PQgetResult(conn);       // Now get the results
>>
> I belive if you're waiting in an event loop, you can use PQsocket() to
> return the fd to use in select. Or if you're doing other work, do that
> while you're waiting and check isBusy when you have time...


Well, I do use select() before calling PQconsumeInput, but I'm not sure what
an event loop would be like.I have more than one (remotly executed) queries
and I want to pick whatever results are available without being blocked (and
even abord a delaying query), i.e. I do have other work to do. Having said
that, I think that an event loop would be appropriate but I'm a little
confused on its structure. Any pointers?

Thanks,
Ntinos Katsaros