From: Noah Misch <noah@leadboat.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: foreign key locks
Date: Sat, 17 Nov 2012 09:56:06 -0500
Message-ID: <20121117145606.GC24972@tornado.leadboat.com> (raw)
In-Reply-To: <20121117142020.GB4222@awork2.anarazel.de>
References: <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>
<20121116002459.GB4347@tornado.leadboat.com>
<20121116161747.GC4454@alvh.no-ip.org>
<20121116163112.GF6505@awork2.anarazel.de>
<20121117033151.GB24972@tornado.leadboat.com>
<20121117142020.GB4222@awork2.anarazel.de>
On Sat, Nov 17, 2012 at 03:20:20PM +0100, Andres Freund wrote:
> On 2012-11-16 22:31:51 -0500, Noah Misch wrote:
> > On Fri, Nov 16, 2012 at 05:31:12PM +0100, Andres Freund wrote:
> > > On 2012-11-16 13:17:47 -0300, Alvaro Herrera wrote:
> > > > Andres is on the verge of convincing me that we need to support
> > > > singleton FOR SHARE without multixacts due to performance concerns.
> > >
> > > I don't really see any arguments against doing so. We aren't in a that
> > > big shortage of flags and if we need more than available I think we can
> > > free some (e.g. XMAX/XMIN_INVALID).
> >
> > The patch currently leaves two unallocated bits. Reclaiming currently-used
> > bits means a binary compatibility break. Until we plan out such a thing,
> > reclaimable bits are not as handy as never-allocated bits. I don't think we
> > should lightly expend one of the final two.
>
> Not sure what you mean with a binary compatibility break?
> pg_upgrade'ability?
Yes. If we decide HEAP_XMIN_INVALID isn't helping, we can stop adding it to
tuples anytime. Old tuples may continue to carry the bit, with no particular
deadline for their demise. To reuse that bit in the mean time, we'll need to
prove that no tuple writable by PostgreSQL 8.3+ will get an unacceptable
interpretation under the new meaning of the bit. Alternately, build the
mechanism to prove that all such old bits are gone before using the bit in the
new way. This keeps HEAP_MOVED_IN and HEAP_MOVED_OFF unavailable today.
> What I previously suggested somewhere was:
>
> #define HEAP_XMAX_SHR_LOCK 0x0010
> #define HEAP_XMAX_EXCL_LOCK 0x0040
> #define HEAP_XMAX_KEYSHR_LOCK (HEAP_XMAX_SHR_LOCK|HEAP_XMAX_EXCL_LOCK)
> /*
> * Different from _LOCK_BITS because it doesn't include LOCK_ONLY
> */
> #define HEAP_LOCK_MASK (HEAP_XMAX_SHR_LOCK|HEAP_XMAX_EXCL_LOCK)
>
> #define HEAP_XMAX_IS_SHR_LOCKED(tup) \
> (((tup)->t_infomask & HEAP_LOCK_BITS) == HEAP_XMAX_SHR_LOCK)
> #define HEAP_XMAX_IS_EXCL_LOCKED(tup) \
> (((tup)->t_infomask & HEAP_LOCK_BITS) == HEAP_XMAX_EXCL_LOCK)
> #define HEAP_XMAX_IS_KEYSHR_LOCKED(tup) \
> (((tup)->t_infomask & HEAP_LOCK_BITS) == HEAP_XMAX_KEYSHR_LOCK)
>
> It makes checking for locks sightly more more complicated, but its not
> too bad...
Agreed; that seems reasonable.
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: noah@leadboat.com, andres@2ndquadrant.com, alvherre@2ndquadrant.com
Subject: Re: foreign key locks
In-Reply-To: <20121117145606.GC24972@tornado.leadboat.com>
* 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