Re: Exposing the Xact commit order to the user

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Exposing the Xact commit order to the user
Date: 2010-05-26 23:48:26
Message-ID: 4BFDB34A.2010007@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/26/2010 4:34 PM, Kevin Grittner wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)com> wrote:
>
>> Without this logic, the replication system could not combine
>> multiple origin sessions into one replication session without
>> risking to never find a state, in which it can commit.
>
> My latest idea for handling this in WAL-based replication involves
> WAL-logging information about the transaction through which a the
> committing transaction makes it safe to view. There are a few
> options here at the detail level that I'm still thinking through.
> The idea would be that the xmin from read-only queries on the slaves
> might be somewhere behind where you would expect based on
> transactions committed. (The details involve such things as where
> non-serializable transactions fall into the plan on both sides, and
> whether it's worth the effort to special-case read-only transactions
> on the master.)
>
> I can't say that I'm 100% sure that some lurking detail won't shoot
> this technique down for HS, but it seems good to me at a conceptual
> level.

Without simulating multiple simultaneous transactions during playback,
how are you going to manage that the tuples, already inserted on behalf
of the ongoing master transactions, disappear when they abort on the master?

Jan

--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gurjeet Singh 2010-05-26 23:54:39 Distclean does not remove gram.c
Previous Message Heikki Linnakangas 2010-05-26 23:39:21 Re: functional call named notation clashes with SQL feature