> On Mar 15, 2021, at 10:34 AM, Julien Rouhaud <rjuju...@gmail.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 <rjuju...@gmail.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