Gregory Stark <stark@enterprisedb.com> writes:
> You could create a whole new index concurrently, then in a completely new
> (third) transaction drop the old one. The problem there is that there could be
> other things (namely foreign key constraints) depending on the old index.
> Fixing them all to depend on the new one may not be a problem or it may, I
> haven't thought it through. Nor have I thought through whether it would be
> possible to keep the original name.
If the idea is to do REINDEX CONCURRENTLY then ISTM you could just swap
the relfilenodes of the two indexes and then zap the new catalog entries
(and old index contents). The problem is exactly the same as before,
though: you need exclusive lock to do that.
regards, tom lane
