| From: | Rod Taylor <pg(at)rbt(dot)ca> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| 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-22 00:39:17 |
| Message-ID: | 1090456756.23763.12.camel@jester |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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.
I don't know if this is the case now or not (I imagine it's pretty good
at cleaning up at the moment), but if we implemented 2 Phase Commit this
logic would need to be removed as transactions need to cross database
restarts.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Kirkwood | 2004-07-22 00:39:59 | Re: PITR COPY Failure (was Point in Time Recovery) |
| Previous Message | Simon Riggs | 2004-07-22 00:21:17 | Re: Why we really need timelines *now* in PITR |