Re: Transaction Snapshots and Hot Standby

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Transaction Snapshots and Hot Standby
Date: 2008-09-15 13:26:01
Message-ID: 48CE6269.2050803@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>
>> So passing xl_xmin from master to standby seems not necessary to me. The
>> standby's OldestXmin needs to be passed through to the master, not the
>> other way around so that WAL records for tuple removal are not
>> generated.
>
> I think most people were pretty leery of doing it that way because it means
> activity on the standby database can cause the master to bloat. The consensus
> seemed to be headed towards having WAL replay on the standby stall if it meets
> a tuple removal record for a tuple that's visible to a query running on it.
> Probably with a mechanism to configure a maximum amount of time it can be
> stalled before shooting those queries.

Yes, but we can quite easily provide an option on top of that to
advertise the slave xmin back to the master, for those who prefer some
bloat on master over stalling replay or killing queries in the slave. In
fact, I think a lot of people will choose some compromise, where the
slave xmin is advertised back to the master, but the master will obey it
only up to some limit, after which the slave will need to stall or kill
queries again.

It's not something that needs to be done in the first phase, but should
be straightforward to add after the basics are working. In any case,
we'll need the capability in the slave to notice when it's about to
remove a tuple that's still visible to a snapshot in the slave.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-09-15 13:28:06 Re: rmgr hooks and contrib/rmgr_hook
Previous Message Simon Riggs 2008-09-15 13:24:23 Re: rmgr hooks and contrib/rmgr_hook