| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Gregory Stark <stark(at)enterprisedb(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 15:13:37 |
| Message-ID: | 1221491617.3913.1412.camel@ebony.2ndQuadrant |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2008-09-15 at 16:26 +0300, Heikki Linnakangas wrote:
> 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.
Looks like what I'll do is this:
Alter functions in pruneheap.c so that we bubble up the latest xid that
is being removed as part of block cleaning. We then add that xid into
the WAL record for cleaning.
If latest xid of clean is ahead of oldestxmin of running queries on
standby then Startup process needs to take action, of some kind.
Re-examining the tuples in WAL apply seems bad plan, since we'd have to
touch stuff in the block twice and juggle the locks.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2008-09-15 15:43:54 | Re: rmgr hooks and contrib/rmgr_hook |
| Previous Message | Tom Lane | 2008-09-15 15:09:02 | Integrating hash index tupledesc hack a bit better |