On Sat, Jan 9, 2010 at 4:25 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> I don't think we need all that, a simple select() should be enough.
> Though I must admit I'm not very familiar with select/poll().
I'm not sure whether poll(2) should be called for this purpose. But
poll(2) and select(2) seem to often come together in the existing code.
We should follow such custom?
>>> * Do we really need to split the sleep in walsender to NAPTIME_PER_CYCLE
>>> increments?
>>
>> Yes. It's required for some platforms (probably HP-UX) in which signals
>> cannot interrupt the sleep.
>
> I'm thinking that the wal_sender_delay is so small that maybe it's not
> worth worrying about.
The same problem exists in walwriter.c, too. Though we can expect that
wal_writer_delay is small, its sleep has been broken down into smaller bit.
We should follow such existing code? Or just remove that feature from
walwriter?
>>> * Walreceiver should flush less aggresively than after each received
>>> piece of WAL as noted by XXX comment.
>>
>>> * XXX: Flushing after each received message is overly aggressive. Should
>>> * implement some sort of lazy flushing. Perhaps check in the main loop
>>> * if there's any more messages before blocking and waiting for one, and
>>> * flush the WAL if there isn't, just blocking.
>>
>> In this approach, if messages continuously arrive from master, the fsync
>> would be delayed until WAL segment is switched. Likewise, recovery also
>> would be delayed, which seems to be problem.
>
> That seems OK to me. If messages are really coming in that fast,
> fsyncing the whole WAL segment at a time is probably most efficient.
OK, I'll implement your idea. But that seems to be inefficient in the
synchronous replication (especially "wait WAL-replay" mode). So let's
revisit this discussion later.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center