"Simon Riggs" <simon@2ndquadrant.com> writes:
> On Thu, 2007-06-21 at 16:05 -0400, Tom Lane wrote:
>> Can we fix it to be a read test instead of a write test, that is, if
>> we know WAL has been flushed through the target LSN, it's safe to set
>> the hint bit, else not?
> Yes, that's roughly how it worked in v1.
> The various possible strategies for handling hint bits were:
> 1. flush WAL to current insert pointer - very heavy perf hit
> 2. defer setting the hint bits at all, if the written transactions are
> recently written. To do this we need a cache of recently written
> deferred commit Xids.
> 3. flush WAL up to the LSN of the Xid, if it is a deferred commit. To do
> this we need a cache of recently written deferred commit Xids.
I think you misunderstood me:
4. If WAL has not been flushed far enough to be certain that the target
transaction's commit is synced, then defer setting the hint bit. This
does not require any new per-transaction state, we can just measure it
on the basis of the lsn associated with the clog page that the
transaction's state is in.
Compared to #2, this gets rid of complexity of bookkeeping at the cost
of not being able to set hint bits as soon as we otherwise could.
I think both #1 and #3 would lose most of the advantage of deferred
commit, as it is not at all uncommon for a transaction's effects to be
examined by the following transaction, so you'd be flushing WAL
immediately just to set hint bits.
regards, tom lane