On Fri, Aug 14, 2026 at 7:39 AM Andrey Borodin <[email protected]> wrote: > > The existing COPY test uses an unlogged relation, so it does not > exercise the WAL eligibility checks in > PrepareOrRejectEagerFlushBuffer(). I tried the same test with a regular > table and it consistently combined writes. > > For deterministic results I used wal_writer_delay = '10ms'. With > synchronous_commit disabled, a fast COPY may otherwise finish before the > default 200ms WAL writer interval. fsync can remain disabled: the test > only needs the PostgreSQL WAL flush position to advance.
I don't think we'll be able to get deterministic test runs of this heuristic. With unlogged tables we are already testing the happy path where nothing gets rejected. If we want to test the case where buffers are rejected due to pending WAL, I think we would need something more surgical. We'd have to be sure that nothing else flushes WAL anywhere. Wal writer, Bgwriter, checkpointer, etc can mostly be disabled with settings but crossing a WAL segment boundary flushes WAL. So, I think it would be pretty hard for us to tell where the WAL is flushed until and make sure the test doesn't flake. Maybe if we can be sure that the WAL segment isn't full? But it seems easy for it to fail incorrectly in the future if people change how much WAL other database operations take that we do before the test. > Perhaps the test could run the COPY case for both unlogged and regular > tables. I added a vacuum test in v16 that uses a logged table to give some coverage of the logged path. It won't give coverage of rejected combining as I make a point to make sure the table doesn't have pending WAL, but it seemed like good variety to add. - Melanie
