Re: concurrent index builds unneeded lock?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Theo Schlossnagle <jesus(at)omniti(dot)com>, PostgreSQL-development Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: concurrent index builds unneeded lock?
Date: 2009-07-12 15:17:04
Message-ID: 15606.1247411824@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> On 7/11/09 3:50 AM, Greg Stark wrote:
>> Hm. Actually maybe not. What if the index is an expression index and
>> the expression includes a function which does an SQL operation? I'm
>> not sure how realistic that is since to be a danger that SQL operation
>> would have to be an insert, update, or delete which is not just
>> bending the rules.

> It's not realistic at all. People are only supposed to use IMMUTABLE
> functions for experession indexes; if they declare a volatile function
> as immutable, then it's their own lookout if they corrupt their data.

The requirement wasn't just on not changing SQL data though. To make
use of this you'd also have to forbid indexed functions from *reading*
other tables. Which is something we discourage because of the risk that
the results aren't really immutable, but we don't forbid it; and there
are obvious use-cases.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2009-07-12 15:28:58 fix: plpgsql: return query and dropped columns problem
Previous Message Pavel Stehule 2009-07-12 15:05:35 Re: Upgrading our minimum required flex version for 8.5