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: Fri, 16 Nov 2012 22:31:51 -0500
Message-ID: <20121117033151.GB24972@tornado.leadboat.com> (raw)
In-Reply-To: <20121116163112.GF6505@awork2.anarazel.de>
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>
<20121116002459.GB4347@tornado.leadboat.com>
<20121116161747.GC4454@alvh.no-ip.org>
<20121116163112.GF6505@awork2.anarazel.de>
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.
> > It
> > would be useful for more people to chime in here: is FOR SHARE an
> > important case to cater for? I wonder if using FOR KEY SHARE (keep
> > performance characteristics, but would need to revise application code)
> > would satisfy Andres' users, for example.
>
> It definitely wouldn't help in the cases I have seen because the point
> is to protect against actual content changes of the rows, not just the
> keys.
> Note that you actually need to use explicit FOR SHARE/UPDATE for
> correctness purposes in many scenarios unless youre running in 9.1+
> serializable mode. And that cannot be used in some cases (try queuing
> for example) because the rollback rates would be excessive.
I agree that tripling FOR SHARE cost is risky. Where is the added cost
concentrated? Perchance that multiple belies optimization opportunities.
Thanks,
nm
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: <20121117033151.GB24972@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