Re: [PATCHES] Reviewers Guide to Deferred Transactions/Transaction Guarantee

"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> transaction_guarantee.v11.patch

I can't help feeling that this is enormously overcomplicated.

The "DFC" in particular seems to not be worth its overhead. Why wouldn't
we simply track the newest commit record at all times, and then whenever
the wal writer wakes up, it would write/fsync that far (or write/fsync
all completed WAL pages, if there's no new commit record to worry
about)?

I see the concern about not letting clog pages go to disk before the
corresponding WAL data is flushed, but that could be handled much more
simply: just force a flush through the newest commit record before any
write of a clog page. Those writes are infrequent enough (every 32K
transactions or one checkpoint) that this seems not a serious problem.

The other interesting issue is not letting hint-bit updates get to disk
in advance of the WAL flush, but I don't see a need to track those at
a per-transaction level: just advance page LSN to latest commit record
any time a hint bit is updated. The commit will likely be flushed
before we'd be interested in writing the buffer out anyway. Moreover,
the way you are doing it creates a conflict in that the DFC has to
guarantee to remember every unflushed transaction, whereas it really
needs to be just an approximate cache for its performance to be good.

AFAIK there is no need to associate any forced flush with multixacts;
there is no state saved across crashes for those anyway.

I don't see a point in allowing the WAL writer to be disabled ---
I believe it will be a performance win just like the bgwriter,
independently of whether transaction_guarantee is used or not,
by helping to keep down the number of dirty WAL buffers. That in
turn allows some other simplifications, like not needing an assign hook
for transaction_guarantee.

I disagree with your desire to remove the fsync parameter. It may have
less use than before with this feature, but that doesn't mean it has
none.

> 3. Should the WALWriter also do the wal_buffers half-full write at the
> start of XLogInsert() ?

That should go away entirely; to me the main point of the separate
wal-writer process is to take over responsibility for not letting too
many dirty wal buffers accumulate.

regards, tom lane