Re: Exposing the Xact commit order to the user - Mailing list pgsql-hackers

From Chris Browne
Subject Re: Exposing the Xact commit order to the user
Date
Msg-id 87aardclzo.fsf@ca.afilias.info
Whole thread Raw
In response to Re: Exposing the Xact commit order to the user  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
heikki.linnakangas@enterprisedb.com (Heikki Linnakangas) writes:
> On 24/05/10 19:51, Kevin Grittner wrote:
>> The only thing I'm confused about is what benefit anyone expects to
>> get from looking at data between commits in some way other than our
>> current snapshot mechanism.  Can someone explain a use case where
>> what Jan is proposing is better than snapshot isolation?  It doesn't
>> provide any additional integrity guarantees that I can see.
>
> Right, it doesn't. What it provides is a way to reconstruct a snapshot
> at any point in time, after the fact. For example, after transactions
> A, C, D and B have committed in that order, it allows you to
> reconstruct a snapshot just like you would've gotten immediately after
> the commit of A, C, D and B respectively. That's useful replication
> tools like Slony that needs to commit the changes of those
> transactions in the slave in the same order as they were committed in
> the master.
>
> I don't know enough of Slony et al. to understand why that'd be better
> than the current heartbeat mechanism they use, taking a snapshot every
> few seconds, batching commits.

I see two advantages:
a) Identifying things on a transaction-by-transaction basis means that   the snapshots ("syncs") don't need to be
captured,which is   presently an area of fragility.  If the slon daemon falls over on   Friday evening, and nobody
noticesuntil Monday, the "snapshot"   reverts to being all updates between Friday and whenever SYNCs   start to be
collectedagain.
 
   Exposing commit orders eliminates that fragility.  SYNCs don't   need to be captured anymore, so they can't be
missed(which is   today's problem).
 
b) The sequence currently used to control log application ordering is   a bottleneck, as it is a single sequence shared
acrossall   connections.
 
   It could be eliminated in favor of (perhaps) an in-memory variable   defined on a per-connection basis.
   It's not a bottleneck that we hear a lot of complaints about, but   the sequence certainly is a bottleneck.

-- 
select 'cbbrowne' || '@' || 'cbbrowne.com';
http://cbbrowne.com/info/internet.html
"MS  apparently now  has a  team dedicated  to tracking  problems with
Linux  and publicizing them.   I guess  eventually they'll  figure out
this back fires... ;)" -- William Burrow <aa126@DELETE.fan.nb.ca>


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Allow wal_keep_segments to keep all segments
Next
From: Robert Haas
Date:
Subject: Re: Allow wal_keep_segments to keep all segments