Alvaro Herrera wrote: > Here's version 24. Old review emails still contains some items that didn't lead to any changes. I tried to keep close track of those. To that list I add a couple of things of my own. Here they are, for those following along. I welcome suggestions.
- Fix the multixact cache in multixact.c -- see mXactCacheEnt. - ResetHintBitMulti() was removed; need to remove old XMAX_IS_MULTI somewhere; perhaps during HOT page pruning? - EvalPlanQual and ExecLockRows maybe need a different overall locking strategy. Right now follow_updates=false is used to avoid deadlocks. - Ensure multixact.c behaves sanely on wraparound. - Is the case of a a non-key-update followed by a key-update actually handled when doing a heap_lock_tuple with mode = LockTupleKeyShare and follow_updates = false? I don't really see how, so it seems to deserve at least a comment. - if oldestMultiXactId + db is set and then that database is dropped we seem to have a problem because MultiXactAdvanceOldest won't overwrite those values. Should probably use SetMultiXactIdLimit directly. - what stop multixacts only being filled out (i.e RecordNewMultiXact()) *after* the XLogInsert() *and* after a MultiXactGetCheckptMulti()? Afaics MultiXactGenLock is not hold in CreateMultiXactId(). If we crash in that moment we loose the multixact data which now means potential data loss... - multixact member group data crossing 512 sector boundaries makes me uneasy (as its 5 bytes). I don't really see a scenario where its dangerous, but ... Does anybody see a problem here? - there are quite some places that do multiStopLimit = multiWrapLimit - 100; if (multiStopLimit < FirstMultiXactId) multiStopLimit -= FirstMultiXactId; perhaps MultiXactIdAdvance and MultiXactIdRetreat macros are in order? - not really padding, MultiXactStatus is 4bytes... /* * XXX Note: there's a lot of padding space in MultiXactMember. We could * find a more compact representation of this Xlog record -- perhaps all the * status flags in one XLogRecData, then all the xids in another one? Not * clear that it's worth the trouble though. */ -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers