From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Transaction Guarantee, updated version |
Date: | 2007-06-22 14:22:38 |
Message-ID: | 21665.1182522158@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
"Simon Riggs" <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2007-06-22 14:26:39 | Re: bitmapscan changes patch review |
Previous Message | Tom Lane | 2007-06-22 14:10:38 | Re: Load Distributed Checkpoints, take 3 |