• Tom Lane's avatar
    Reduce the number of GetFlushRecPtr() calls done by walsenders. · e369f370
    Tom Lane authored
    Since the WAL flush position only moves forward, it's safe to cache
    its previous value within each walsender process, and update from
    shared memory only once we've caught up to the previously-seen value.
    When there are many active walsenders, this makes for a very significant
    reduction in the amount of contention on the XLogCtl->info_lck spinlock.
    
    This patch also adjusts the logic so that we update our idea of the
    flush position after processing a WAL record, rather than beforehand.
    This may cause us to realize we're not caught up when the preceding
    coding would've thought that we were, but that seems all to the good;
    it may avoid a useless sleep-and-wakeup cycle.
    
    Back-patch to v12.  The contention problem exists in prior branches,
    but it's much less severe (due to inefficiencies elsewhere) so there
    seems no need to take any risk of back-patching further.
    
    Pierre Ducroquet, reviewed by Julien Rouhaud
    
    Discussion: https://postgr.es/m/2931018.Vxl9zapr77@pierred-pdoc
    e369f370
walsender.c 101 KB