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
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 |