On Tue, May 19, 2015 at 5:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Geoghegan <pg@heroku.com> writes:
>> I think I agree with you, though: We should change things so that the
>> relcache gives indexes in something like the ordering that you
>> outline, rather than in the current arbitrary (though consistent) OID
>> order.
>
> I'm fairly sure that there are aspects of the code that rely on indexes
> being returned by RelationGetIndexList() in a stable order. While I doubt
> that has to be exactly increasing-OID-order, I'm quite concerned about
> allowing the order to depend on mutable aspects of the indexes, like
> names.
I thought the importance of the ordering was just down to some AMs
(like hash) using heavyweight locks. This could cause unprincipled
deadlocks in the face of an inconsistent ordering. nbtree used to use
page-level heavyweight locks many years ago, too, so this used to be a
big, obvious requirement. Maybe there is another reason, but AFAICR
there are no hints of that from the relevant code, and I've looked
carefully.
If it was ever changed, I think it could be done in a way that didn't
add any problems, assuming I've accounted for all the ways in which
changing the ordering could be problematic.
--
Peter Geoghegan
