Re: WAL recycling, Linux 2.4.18

Curt Sampson <cjs(at)cynic(dot)net> writes:
> Well, depending on how the OS schedules writes, one process doing
> a huge amount of writing might well slow down everything else a
> lot, unless you've got a really good disk system.

It's currently looking like an fdatasync applied to a single file
might get blocked behind a global sync in his system. Does that
ring a bell with anyone?

> But is it possible for a process to commit a transaction while a
> checkpoint is in progress?

You bet.

> That would mean that it's ok for the
> checkpoint record to be after a bunch of transactions that are not
> part of the checkpoint, right?

Right. The physical position of the checkpoint record is distinct
from its logical position, if you will. There's a back-pointer in
the checkpoint record showing where the end of WAL was when the
checkpointer started, and any replay has to start there, not at the
physical position of the checkpoint record. Records in between were
emitted while the checkpoint ran, and so their effects might or might
not have been synced to disk by the checkpoint.

regards, tom lane