On Wed, Feb 8, 2023 at 9:57 AM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > > I can also do a few other things, but before working on them, I'd like > to hear from others: > 1. A separate wait event (WAIT_EVENT_WAL_READ_FROM_BUFFERS) for > reading from WAL buffers - right now, WAIT_EVENT_WAL_READ is being > used both for reading from WAL buffers and WAL files. Given the fact > that we won't wait for a lock or do a time-taking task while reading > from buffers, it seems unnecessary.
Yes, we do not need this separate wait event and we also don't need WAIT_EVENT_WAL_READ wait event while reading from the buffer. Because we are not performing any IO so no specific wait event is needed and for reading from the WAL buffer we are acquiring WALBufMappingLock so that lwlock event will be tracked under that lock. > 2. A separate TAP test for verifying that the WAL is actually read > from WAL buffers - right now, existing tests for recovery, > subscription, pg_walinspect already cover the code, see [1]. However, > if needed, I can add a separate TAP test. Can we write a test that can actually validate that we have read from a WAL Buffer? If so then it would be good to have such a test to avoid any future breakage in that logic. But if it is just for hitting the code but no guarantee that whether we can validate as part of the test whether it has hit the WAL buffer or not then I think the existing cases are sufficient. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com