Re: REINDEX backend filtering

> On Mar 15, 2021, at 10:34 AM, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>
> On Mon, Mar 15, 2021 at 10:13:55AM -0700, Mark Dilger wrote:
>>
>>
>>> On Mar 15, 2021, at 9:52 AM, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>>>
>>> But there are also the tests in collate.icu.utf8.out which will fake outdated
>>> collations (that's the original tests for the collation tracking patches) and
>>> then check that outdated indexes are reindexed with both REINDEX and REINDEX
>>> (OUDATED).
>>>
>>> So I think that all cases are covered. Do you want to have more test cases?
>>
>> I thought that just checked cases where a bogus 'not a version' was put into pg_catalog.pg_depend. I'm talking about having a collation provider who returns a different version string and has genuinely different collation rules between versions, thereby breaking the index until it is updated. Is that being tested?
>
> No, we're only checking that the infrastructure works as intended.
>
> Are you saying that you want to implement a simplistic collation provider with
> "tunable" ordering, so that you can actually check that an ordering change will
> be detected as a corrupted index, as in you'll get some error or incorrect
> results?

I'm saying that your patch seems to call down to get_collation_actual_version() via get_collation_version_for_oid() from your new function do_check_index_has_outdated_collation(), but I'm not seeing how that gets exercised.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company