Re: cheaper snapshots

From: Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: cheaper snapshots
Date: 2011-07-28 23:54:13
Message-ID: CA+CSw_vdtyGFsJgk5J+cJjib8J5SSwvTjkcFfqv77GCHZ6TdVw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 28, 2011 at 11:54 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> (4)  We communicate acceptable snapshots to the replica to make the
> order of visibility visibility match the master even when that
> doesn't match the order that transactions returned from commit.

I wonder if some interpretation of 2 phase commit could make Robert's
original suggestion implement this.

On the master the commit sequence would look something like:
1. Insert commit record to the WAL
2. Wait for replication
3. Get a commit seq nr and mark XIDs visible
4. WAL log the seq nr
5. Return success to client

When replaying:
* When replaying commit record, do everything but make
the tx visible.
* When replaying the commit sequence number
if there is a gap between last visible commit and current:
insert the commit sequence nr. to list of waiting commits.
else:
mark current and all directly following waiting tx's visible

This would give consistent visibility order on master and slave. Robert
is right that this would undesirably increase WAL traffic. Delaying this
traffic would undesirably increase replay lag between master and slave.
But it seems to me that this could be an optional WAL level on top of
hot_standby that would only be enabled if consistent visibility on
slaves is desired.

--
Ants Aasma

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ants Aasma 2011-07-29 00:12:07 Re: cheaper snapshots
Previous Message Robert Haas 2011-07-28 23:45:01 Re: error: could not find pg_class tuple for index 2662