From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: foreign key locks
Date: Tue, 27 Nov 2012 12:07:34 -0300
Message-ID: <20121127150734.GI4227@alvh.no-ip.org> (raw)
In-Reply-To: <20121126194554.GD4227@alvh.no-ip.org>
References: <4FEAB90A0200002500048B7D@gw.wicourts.gov>
<1346389151-sup-8379@alvh.no-ip.org>
<20121018195820.GO3763@alvh.no-ip.org>
<201210270006.54728.andres@2ndquadrant.com>
<20121114152347.GA5161@alvh.no-ip.org>
<20121114162726.GE5161@alvh.no-ip.org>
<20121119115804.GA28067@awork2.anarazel.de>
<20121120203614.GA26623@alvh.no-ip.org>
<20121120211533.GA4171@awork2.anarazel.de>
<20121126194554.GD4227@alvh.no-ip.org>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@2ndquadrant.com, andres@2ndquadrant.com
Subject: Re: foreign key locks
In-Reply-To: <20121127150734.GI4227@alvh.no-ip.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox