| From: | Zeugswetter Andreas OSB sIT <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Chris Browne <cbbrowne(at)acm(dot)org>, Jochem van Dieten <jochemd(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Hannu Krosing <hannu(at)2ndQuadrant(dot)com>, Richard Huxton <dev(at)archonet(dot)com> |
| Subject: | Re: Transaction Snapshots and Hot Standby |
| Date: | 2008-09-25 10:34:25 |
| Message-ID: | 6DAFE8F5425AB84DB3FCA4537D829A561CE05C7235@M0164.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > I wonder whether the cancel can be delayed until a tuple/page is actually accessed
> > that shows a too new xid.
>
> Yes, its feasible and is now part of the design.
>
> This is all about what happens *if* we need to remove rows that a query
> can still see.
I was describing a procedure for exactly that case.
If a slave backend has a snapshot that we cannot guarantee any more
(because max_slave_delay has been exceeded):
> > Instead of cancel, the backend gets a message with a lsn_horizon.
> > From there on, whenever the backend reads a page/tuple with a LSN > lsn_horizon it cancels.
but not before (at the time max_slave_delay has been reached), as described earlier.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2008-09-25 12:05:07 | Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep) |
| Previous Message | Zdenek Kotala | 2008-09-25 10:07:54 | Re: PostgreSQL future ideas |