Re: Exposing the Xact commit order to the user

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Exposing the Xact commit order to the user
Date: 2010-06-02 18:44:59
Message-ID: 87aardclzo.fsf@ca.afilias.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

heikki(dot)linnakangas(at)enterprisedb(dot)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 notices until Monday, the "snapshot"
reverts to being all updates between Friday and whenever SYNCs
start to be collected again.

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 across all
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(at)DELETE(dot)fan(dot)nb(dot)ca>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2010-06-02 19:10:23 Re: Idea for getting rid of VACUUM FREEZE on cold pages
Previous Message Tom Lane 2010-06-02 18:44:43 "caught_up" status in walsender