Re: concurrent index builds unneeded lock?

Greg Stark <gsstark(at)mit(dot)edu> writes:
> I wonder whether an earlier more general proposal could have some
> leverage here though: some way to indicate that the transaction has
> taken all the locks it plans to take already. This was originally
> proposed as a way for vacuum to know it can ignore the snapshots of a
> transaction since it isn't going to access the table being vacuumed.

Again, this doesn't work for any interesting cases. You can't for
example assume that a user-defined datatype won't choose to look into
tables that hadn't been accessed as of the start of the index build.
(This isn't a hypothetical example --- I believe PostGIS does some
such things already, because it keeps spatial reference definitions
in a central catalog table.)

regards, tom lane