| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>, "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Bug in VACUUM FULL ? |
| Date: | 2007-03-10 18:38:18 |
| Message-ID: | 871wjx0wrp.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> [ raised eyebrow... ] You sure about that? If you replace an XID
> before OldestXmin with one after, or vice versa, ISTM you *could*
> be creating a problem. "Committed" is not good enough. So it looks
> to me like you can't remove a DEAD tuple whose predecessor is only
> RECENTLY_DEAD.
Except you're replacing it with the xmax of a tuple that while you can't prove
it using OldestXmin you're convinced is in fact really DEAD. So everyone
should be able to see the txn id you're substituting.
It seems safer to remove all the tuples you think are DEAD rather than leave
them and have hidden assumptions that you're right. It would be far easier to
test that you're not removing tuples that aren't dead than that you aren't
breaking the chain or substituting a live xmin in cases where it might matter.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2007-03-10 19:53:57 | Re: what can be wrong? backport plpgpsm to 8.1 |
| Previous Message | Pavan Deolasee | 2007-03-10 18:33:00 | Re: Bug in VACUUM FULL ? |