heikki.linnakan...@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 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 <aa...@delete.fan.nb.ca>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
