| From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Richard Huxton <dev(at)archonet(dot)com> |
| Subject: | Re: Transaction Snapshots and Hot Standby |
| Date: | 2008-09-11 13:33:11 |
| Message-ID: | 200809111533.14054.dfontaine@hi-media.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Le jeudi 11 septembre 2008, Heikki Linnakangas a écrit :
> 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.
What would forbid the slave to choose to replay all currently lagging WALs
each time it's given the choice to advance a little?
--
dim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Csaba Nagy | 2008-09-11 13:38:25 | Re: Transaction Snapshots and Hot Standby |
| Previous Message | Csaba Nagy | 2008-09-11 13:32:03 | Re: Transaction Snapshots and Hot Standby |