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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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