"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. 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?
regards, tom lane