Re: Transaction Snapshots and Hot Standby - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Transaction Snapshots and Hot Standby
Date
Msg-id 48CE6269.2050803@enterprisedb.com
Whole thread Raw
In response to Re: Transaction Snapshots and Hot Standby  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Transaction Snapshots and Hot Standby  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Transaction Snapshots and Hot Standby  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Gregory Stark wrote:
> Simon Riggs <simon@2ndQuadrant.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


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Synchronous Log Shipping Replication
Next
From: Gregory Stark
Date:
Subject: Re: rmgr hooks and contrib/rmgr_hook