Re: More vacuum.c refactoring - Mailing list pgsql-hackers

From Tom Lane
Subject Re: More vacuum.c refactoring
Date
Msg-id 19745.1086931515@sss.pgh.pa.us
Whole thread Raw
In response to Re: More vacuum.c refactoring  (Manfred Koizar <mkoi-pg@aon.at>)
Responses Re: More vacuum.c refactoring
List pgsql-hackers
Manfred Koizar <mkoi-pg@aon.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


pgsql-hackers by date:

Previous
From: Shridhar Daithankar
Date:
Subject: Re: Why frequently updated tables are an issue
Next
From: Tom Lane
Date:
Subject: Re: More vacuum.c refactoring