| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Rod Taylor <pg(at)rbt(dot)ca> |
| Cc: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, Gaetano Mendola <mendola(at)bigfoot(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: check point segments leakage ? |
| Date: | 2004-07-21 20:53:02 |
| Message-ID: | 1090443182.2658.1316.camel@localhost.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 2004-07-21 at 18:54, Rod Taylor wrote:
> > I don't know why the 1st VACUUM FULL wasn't able to reclaim the same
> > amount of space as the 2nd one, but I would guess that it wasn't able to
> > get a lock on some table. It could have been autovac if it was doing a
> > vacuum at that moment, but it could have been something else too.
>
> Or there was a long running transaction in the background. The oldest
> active transaction will place limits on what VACUUM can or cannot
> remove.
>
What happens when a transaction fails to either commit or abort as a
result of a serious error?
That looks like a transaction-in-progress doesn't it?
Would that prevent VACUUM from doing its work? It should be able to
check the last startup xid to check that isn't the case, but suppose a
backend had exited without taking down the postmaster.
(...waits for thunder...)
Best Regards, Simon Riggs
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oliver Jowett | 2004-07-21 21:03:44 | Re: parameter hints to the optimizer |
| Previous Message | Oliver Jowett | 2004-07-21 20:50:52 | Re: V3 protocol + DECLARE problems |