From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Manfred Koizar <mkoi-pg(at)aon(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: More vacuum.c refactoring |
Date: | 2004-06-19 03:05:29 |
Message-ID: | 200406190305.i5J35TI15948@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Where are we on this?
---------------------------------------------------------------------------
Tom Lane wrote:
> Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> > I understand you, honestly. Do I read between your lines that you
> > didn't review my previous vacuum.c refactoring patch? Please do. It'd
> > make *me* more comfortable.
>
> I did not yet, but I will get to it. I encourage everyone else to
> take a look too. I agree with Alvaro that fooling with this code
> merits extreme caution.
>
> BTW, I do not at all mean to suggest that vacuum.c contains no bugs
> at the moment ;-). I suspect for example that it is a bit random
> about whether MOVED_OFF/MOVED_IN bits get cleared immediately, or
> only by the next transaction that chances to visit the tuple. The
> next-transaction-fixup behavior has to be there in case the VACUUM
> transaction crashes, but that doesn't mean that VACUUM should
> deliberately leave work undone.
>
> > I see three significant differences between the code in repair_frag()
> > and vacuum_page().
>
> Will study these comments later, but it's too late at night here...
> again, the more eyeballs on this the better...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-06-19 03:07:00 | Re: Why frequently updated tables are an issue |
Previous Message | Bruce Momjian | 2004-06-19 03:04:47 | Re: [PATCHES] serverlog function (log_destination file) |