Re: Streaming replication and non-blocking I/O

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Streaming replication and non-blocking I/O
Дата
Msg-id 4B234FA2.8000900@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Streaming replication and non-blocking I/O  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Streaming replication and non-blocking I/O  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Streaming replication and non-blocking I/O  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
Fujii Masao wrote:
> On Thu, Dec 10, 2009 at 12:00 AM, Tom Lane <tgl@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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: status update on Hot Standby and Streaming Replication
Следующее
От: Greg Smith
Дата:
Сообщение: Re: new CommitFest states