Re: Streaming replication and non-blocking I/O

On Sat, Dec 12, 2009 at 5:09 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> 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.

On a related issue, so far I haven't considered about the way to output
the notice message at all :( In the current SR, it's always written to
stderr by the defaultNoticeProcessor by using fprintf, whether the
log_destination is specified or not. This is bizarre, and would need to
be fixed.

I'm going to set the new function calling ereport as the current notice
processor by using PQsetNoticeProcessor. But the problem is that only the
completed message like "NOTICE: xxx" is passed to such notice processor,
i.e., the error level itself is not passed.

So I wonder which error level should be used to output the notice message.
There are some approaches to address this;

1. Always use a specific level without regard to the actual one
2. Reverse-engineer the level from the complete message
3. Change some libpq functions so as to pass the error level to the notice
processor

But nothing really stands out. Do you have another good idea?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center