Re: Add progressive backoff to XactLockTableWait functions - Mailing list pgsql-hackers

Hi,

During a short 100-second pg_create_logical_replication_slot benchmark
in standby, I compared HEAD with patch v7. v7 removes the
XactLockTableWait polling hot-spot (it no longer shows up in the flame
graph), yet the overall perf-counter numbers are only modestly lower,
suggesting something abnormal .

HEAD

  cycles:           2,930,606,156
  instructions:     1,003,179,713   (0.34 IPC)
  cache-misses:       144,808,110
  context-switches:        77,278
  elapsed:          100 s

v7

  cycles:           2,121,614,632
  instructions:       802,200,231   (0.38 IPC)
  cache-misses:       100,615,485
  context-switches:        78,120
  elapsed:          100 s

Profiling shows a second hot-spot in read_local_xlog_page_guts(),
which still relies on a check/sleep loop.
There’s also a todo suggesting further improvements:
    /*
     * Loop waiting for xlog to be available if necessary
     *
     * TODO: The walsender has its own version of this function, which uses a
     * condition variable to wake up whenever WAL is flushed. We could use the
     * same infrastructure here, instead of the check/sleep/repeat style of
     * loop.
     */

To test the idea, I implemented an experimental patch.  With both v7
and this change applied, the polling disappears from the flame graph
and the counters drop by roughly orders of magnitude:

v7 + CV in read_local_xlog_page_guts

  cycles:               6,284,633
  instructions:         3,990,034   (0.63 IPC)
  cache-misses:           163,394
  context-switches:             6
  elapsed:            100 s

I plan to post a new patch to fix this as well after further
refinements and tests.

Best,
Xuneng