Tom Lane wrote:
>
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> >> Hmmm ... it looks like REINDEX only grabs AccessShareLock on the target
> >> relation, which seems very wrong.
>
> > Sorry I couldn't find where AccessShareLock is grabbed now.
> > AccessExclusiveLock is acquired in reindex_index but do you
> > mean it's too late ?
>
> I was looking at reindex_relation, which doesn't seem to grab anything
> higher than AccessShareLock at all. But in any case, I think you should
> be holding a lock on the parent table a lot sooner than you do, and
> should not release it until transaction commit. reindex_relation ought
> to be holding some lock on the table from the very start, IMHO.
OK I don't object to it.
> Maybe
> AccessExclusiveLock is more than is needed, but I'd want to see a good
> argument that it's safe not to hold an exclusive lock while you're doing
> this stuff. What happens if two backends try to REINDEX at the same time?
One backend would be blocked by another one because reindex_relation
calls reindex_index and reindex_index grabs an ExclusiveLock on the
relation.
Am I missing anything ?
regards,
Hiroshi Inoue
>
> regards, tom lane
