Re: Checkpointer write combining

On Fri, Aug 14, 2026 at 7:39 AM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> 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