Skip site navigation (1) Skip section navigation (2)

Re: improving foreign key locks

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: improving foreign key locks
Date: 2010-11-29 21:56:50
Message-ID: 1291067699-sup-7174@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Excerpts from Tom Lane's message of lun nov 29 18:33:19 -0300 2010:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Excerpts from Alvaro Herrera's message of lun nov 29 18:00:55 -0300 2010:
> >> Additionally, we'd have to expend some more cycles at the parse analysis
> >> phase (of the "FOR SHARE OF x.col1, x.col2" query) to verify that those
> >> columns belong into some non-partial unique index.

> Checking for existence of a unique index at parse analysis time is quite
> horrid anyway, because it means the validity of the query can change
> from parse time to execution time.  We got stuck with some of that in
> relation to GROUP BY dependencies, but I don't want to buy into it
> anywhere that we're not forced to by the letter of the SQL spec.

Hmm.  Are you less opposed to the idea of some new nonstandard syntax in
the locking clause, then?  I propose "SELECT FOR KEY LOCK", though
anything that the RI code could use would be the same to me, of course.

-- 
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2010-11-29 22:38:48
Subject: Re: [PATCH] V3: Idle in transaction cancellation
Previous:From: Tom LaneDate: 2010-11-29 21:33:19
Subject: Re: improving foreign key locks

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group