Re: concurrent index builds unneeded lock? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: concurrent index builds unneeded lock?
Date
Msg-id 19418.1247328134@sss.pgh.pa.us
Whole thread Raw
In response to Re: concurrent index builds unneeded lock?  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.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


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: *_collapse_limit, geqo_threshold
Next
From: Tom Lane
Date:
Subject: Re: *_collapse_limit, geqo_threshold