Skip site navigation (1) Skip section navigation (2)

Re: Transaction Guarantee, updated version

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: (view raw, whole thread or download thread mbox)
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

In response to


pgsql-patches by date

Next:From: Joshua D. DrakeDate: 2007-06-22 14:26:39
Subject: Re: bitmapscan changes patch review
Previous:From: Tom LaneDate: 2007-06-22 14:10:38
Subject: Re: Load Distributed Checkpoints, take 3

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group