On Mon, Jun 22, 2015 at 7:24 AM, Andres Freund <and...@anarazel.de> wrote: > It'd be very welcome to see some wider testing and review on this.
I started looking at this and doing some testing. Here is some initial feedback: Perhaps vac_truncate_clog needs a new name now that it does more, maybe vac_truncate_transaction_logs? MultiXactState->sawTruncationCkptCyle: is 'Cyle' supposed to be 'Cycle'? In the struct xl_multixact_truncate, and also the function WriteMTruncateXlogRec and other places, I think you have confused the typedefs MultiXactOffset and MultiXactId. If I'm not mistaken, startMemb and endMemb have the correct type, but startOff and endOff should be of type MultiXactId despite their names (the *values* stored inside pg_multixact/offsets are indeed offsets (into pg_multixact/members), but their *location* is what a multixact ID represents). I was trying to understand if there could be any problem caused by setting latest_page_number to the pageno that holds (or will hold) xlrec.endOff in multixact_redo. The only thing that jumps out at me is that the next call to SlruSelectLRUPage will no longer be prevented from evicting the *real* latest page (the most recently created page). In SlruDeleteSegment, is it OK to call unlink() while holding the SLRU control lock? In find_multixact_start you call SimpleLruFlush before calling SimpleLruDoesPhysicalPageExist. Should we do something like this instead? https://gist.github.com/macdice/8e5b2f0fe3827fdf3d5a I think saw some extra autovacuum activity that I didn't expect in a simple scenario, but I'm not sure and will continue looking tomorrow. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
