Re: concurrent index builds unneeded lock?

On Sun, Jul 12, 2009 at 4:17 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Well it's my fault but the discussion kind of mutated in the middle.
For the original use case I think only changing SQL data would
actually be a threat. The concurrent index build only has to wait out
any transactions which might update the table without updating the
index. Which, even if there are volatile functions in the index
expression, index where clause, or index operators, they aren't really
likely to do.

The other thing is that the worst case if they do is you end up with a
corrupted index which is missing entries or has duplicate entries.
That's the same risk you always have if you have volatile functions
mismarked and used in your index definition.

For the mutated discussion where I was trying to find a mechanism that
would be more generally useful that's not the case. Vacuum needs to
know whether you ever plan to *read* from a table in the future. But
that's not what concurrent index builds need to know.

So I think we're back to looking at a special case for concurrent
index builds to not wait on other concurrent index builds.
--
greg
http://mit.edu/~gsstark/resume.pdf