From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Noah Misch <noah@leadboat.com>
Cc: Nikolas Everett <nik9000@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Exhaustive list of what takes what locks
Date: Tue, 22 Feb 2011 22:34:08 -0500
Message-ID: <12631.1298432048@sss.pgh.pa.us> (raw)
In-Reply-To: <AANLkTikNzBfCQxsfed6qYTv0GrYZ8vM1wjwStjd8PwT=@mail.gmail.com>
References: <AANLkTiksaoSZ03m_jALCBwhfogZxNA5_wKo_3J6ydBfF@mail.gmail.com>
<20110202052004.GA26098@tornado.gateway.2wire.net>
<AANLkTikNzBfCQxsfed6qYTv0GrYZ8vM1wjwStjd8PwT=@mail.gmail.com>
Robert Haas <robertmhaas@gmail.com> writes:
> The problem is that constraints can affect the query plan. If a
> transaction sees the constraint in the system catalogs (under
> SnapshotNow) but the table data doesn't conform (under some earlier
> snapshot) and if the chosen plan depends on the validity of the
> constraint, then we've got trouble. At least when running at READ
> COMMITTED, taking an AccessExclusiveLock protects us against that
> hazard (I'm not exactly sure what if anything protects us at higher
> isolation levels... but I hope there is something).
Interesting point. If we really wanted to make that work "right",
we might have to do something like the hack that's in place for CREATE
INDEX CONCURRENTLY, wherein there's a notion that an index can't be used
by a transaction with xmin before some horizon. Not entirely convinced
it's worth the trouble, but ...
> Now, it's true that in the specific case of a foreign key constraint,
> we don't currently have anything in the planner that depends on that.
> But I'm hoping to get around to working on inner join removal again
> one of these days.
Yeah, that sort of thing will certainly be there eventually.
regards, tom lane
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-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, noah@leadboat.com, nik9000@gmail.com
Subject: Re: Exhaustive list of what takes what locks
In-Reply-To: <12631.1298432048@sss.pgh.pa.us>
* 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