| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Hot Standby dev build (v8) |
| Date: | 2009-01-16 21:15:05 |
| Message-ID: | 1232140505.31669.102.camel@ebony.2ndQuadrant |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2009-01-16 at 22:09 +0200, Heikki Linnakangas wrote:
> >> RecentGlobalXmin is just a hint, it lags behind the real oldest xmin
> >> that GetOldestXmin() would return. If another backend has a more recent
> >> RecentGlobalXmin value, and has killed more recent tuples on the page,
> >> the latestRemovedXid written here is too old.
> >
> > What do you think we should do instead?
>
> Dunno. Maybe call GetOldestXmin().
We are discussing btree deletes, not btree vacuums. If we are doing
btree delete then we have an unreleased snapshot therefore we also have
a non-zero xmin. How can another backend have a later RecentGlobalXmin
or result from GetOldestXmin() than we do?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pasher | 2009-01-16 21:34:22 | Re: Autovacuum daemon terminated by signal 11 |
| Previous Message | Peter Eisentraut | 2009-01-16 20:41:03 | Re: PL test fails on several animals |