Re: foreign key locks

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