On Sat, Jan 9, 2010 at 4:25 PM, Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers