Fujii Masao wrote: > On Thu, Dec 10, 2009 at 12:00 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> The OS buffer is expected to be able to store a large number of >>> XLogRecPtr messages, because its size is small. So it's also OK >>> to just drop it. >> It certainly seems to be something we could improve later, when and >> if evidence emerges that it's a real-world problem. For now, >> simple is beautiful. > > I just dropped the backend libpq changes related to non-blocking I/O. > > git://git.postgresql.org/git/users/fujii/postgres.git > branch: replication
Thanks, much simpler now. Changing the finish_time argument to pqWaitTimed into timeout_ms changes the behavior connect_timeout option to PQconnectdb. It should wait for max connect_timeout seconds in total, but now it is waiting for connect_timeout seconds at each step in the connection process: opening a socket, authenticating etc. Could we change the API of PQgetXLogData to be more like PQgetCopyData? I'm thinking of removing the timeout argument, and instead looping with select/poll and PQconsumeInput in the caller. That probably means introducing a new state analogous to PGASYNC_COPY_IN. I haven't thought this fully through yet, but it seems like it would be good to have a consistent API. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers