Andrey Borodin <x4mmm@yandex-team.ru> writes:
> This happens because WaitForLockersMultiple() does not take prepared
> xacts into account.
Ugh, clearly an oversight.
> Meanwhile CREATE INDEX CONCURRENTLY expects that locks are dropped only
> when transaction commit is visible.
Don't follow your point here --- I'm pretty sure that prepared xacts
continue to hold their locks.
> PFA draft of a fix.
Haven't you completely broken VirtualXactLock()? Certainly, whether the
target is a normal or prepared transaction shouldn't alter the meaning
of the "wait" flag.
In general, I wonder whether WaitForLockersMultiple and GetLockConflicts
need to gain an additional parameter indicating whether to consider
prepared xacts. It's not clear to me that their current behavior is wrong
for all possible uses.
regards, tom lane