On Tue, Sep 1, 2015 at 9:25 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > The next problem is that the master can be waiting quite a long time for a > reply from the remote walreceiver containing the desired apply LSN: in the > best case it learns of apply progress from replies to subsequent unrelated > records (which might be very soon on a busy system but still involves > waiting for the next transaction's WAL flush), and in the worst case it > needs to wait for wal_receiver_status_interval (10 seconds by default), > which makes for a long COMMIT delay. I was thinking that the solution to > that may be to teach StartupLOG to signal the walreceiver after it updates > XLogCtl->lastReplayedEndRecPtr, which should cause walrcv_receive to be > interrupted and return early, and then walreceiver could send a reply if it > sees that lastReplayedEndRecPtr has moved. Maybe that would generate an > unacceptably high frequency of signals, and maybe there is a better form of > IPC for this.
Yeah, that could be a problem, as could reply volume. If you've got a bunch of heap inserts of narrow rows into some table, you don't really want to send a reply after each one. That would be a lot of replies, and nobody can really care about them anyway, at least not for synchronous_commit purposes. But what if you only sent a signal when the just-replayed record was a COMMIT record? I suppose that could still be a lot of replies on something like a full-tilt pgbench workload, but even in that case it would help a lot. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
