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

From Heikki Linnakangas
Subject Re: Transaction Snapshots and Hot Standby
Date
Msg-id 48C91AF0.7010804@enterprisedb.com
Whole thread Raw
In response to Re: Transaction Snapshots and Hot Standby  (Csaba Nagy <nagy@ecircle-ag.com>)
Responses Re: Transaction Snapshots and Hot Standby  (Csaba Nagy <nagy@ecircle-ag.com>)
Re: Transaction Snapshots and Hot Standby  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
Csaba Nagy wrote:
> On Thu, 2008-09-11 at 15:42 +0300, Heikki Linnakangas wrote:
>> One problem with this, BTW, is that if there's a continuous stream of 
>> medium-length transaction in the slave, each new snapshot taken will 
>> prevent progress in the WAL replay, so the WAL replay will advance in 
>> "baby steps", and can fall behind indefinitely.
> 
> Why would it fall behind indefinitely ? It only should fall behind to
> the "blocking horizon", which should be the start of the longest
> currently running transaction... which should be continually advancing
> and not too far in the past if there are only medium length transactions
> involved.

Well, yes, but you can fall behind indefinitely that way. Imagine that 
each transaction on the slave lasts, say 10 minutes, with a new 
transaction starting every 5 minutes. On the master, there's a table 
that's being vacuumed (or HOT-updated) frequently, say after each 
transaction for simplicity. What can happen is that every transaction 
that finishes on the slave will only let the WAL replay advance by one 
XID before blocking on the snapshot of the next slave transaction. The 
WAL replay will advance at a rate of 0.2 TPM, while the master is 
generating 1.0 TPM.

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


pgsql-hackers by date:

Previous
From: "Jochem van Dieten"
Date:
Subject: Re: Transaction Snapshots and Hot Standby
Next
From: "Robert Haas"
Date:
Subject: Re: Transaction Snapshots and Hot Standby