From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Adriaan Joubert" <a(dot)joubert(at)albourne(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: [HACKERS] BlowAwayRelationBuffers |
Date: | 2000-01-13 04:05:41 |
Message-ID: | 000501bf5d7b$74ba7300$2801007e@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> > I commited the following change to REL tree after 6.5.2.
> > It might be late for Adriaan.
>
> > ! if (SharedBufferChanged)
> > TransactionIdAbort(xid);
>
> > ! if (SharedBufferChanged && !TransactionIdDidCommit(xid))
> > TransactionIdAbort(xid);
>
> OK, I guess the point is that if VACUUM aborts at some time after
> it's done its internal commit, this code would have un-done the
> commit, thereby allowing HEAP_MOVED_OFF tuples to spring back to
> life?
>
Yes.
> I was trying to figure out if this change might fix the duplicate-
> tuples-after-failed-VACUUM problems that we've just been hearing
> about. Certainly there is plenty of stuff going on in VACUUM after
> its internal commit, so plenty of places that could elog(ERROR).
> But it looks like the very first thing that happens after commit
> is a scan to commit HEAP_MOVED_IN tuples and kill HEAP_MOVED_OFF
Certainly when BlowAwayRelationBuffers() is called,commit to HEAP_
MOVED_IN(OFF) was already completed.
However it seems that the pages which are about to be truncated
are not touched.
Regards.
Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | SAKAIDA | 2000-01-13 04:18:56 | Re: [HACKERS] libpq+MB/putenv(), getenv() clean up |
Previous Message | Tatsuo Ishii | 2000-01-13 03:52:12 | Re: [HACKERS] libpq+MB/putenv(), getenv() clean up |