On Tue, Sep 1, 2015 at 9:25 PM, Thomas Munro
<thomas.munro@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
