From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Bogus collation version recording in recordMultipleDependencies |
Date: | 2021-05-05 20:58:08 |
Message-ID: | 4ad28077-1063-5a03-ef90-b92cee7f6749@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/21/21 4:28 PM, Andres Freund wrote:
> Hi,
>
> On 2021-04-20 12:05:27 +1200, Thomas Munro wrote:
>> I'll hold off reverting for a few more days to see if anyone has any
>> other thoughts on that, because there doesn't seem to be any advantage
>> in being too hasty about it.
> I'm not really convinced that this is warranted, and that it isn't
> better addressed by reducing the scope of the feature:
>
> When using index collation versions to decide whether to reindex
> individual indexes it is important to not have any false negatives -
> otherwise the feature could trigger corruption.
>
> However, the feature has a second, IMO more crucial, aspect: Preventing
> silent corruption due to collation changes. There are regular reports of
> people corrupting their indexes (and subsequently constraints) due to
> collation changes (or collation differences between primary/replica).
> To be effective detecting such cases it is not required to catch 100% of
> all dangerous cases, just that a high fraction of cases is caught.
>
> And handling the composite type case doesn't seem like it'd impact the
> percentage of detected collation issues all that much. For one, indexes
> on composite types aren't all that common, and additing new columns to
> those composite types is likely even rarer. For another, I'd expect that
> nearly all databases that have indexes on composite types also have
> indexes on non-composite text columns - which'd be likely to catch the
> issue.
>
> Given that this is a regularly occurring source of corruption for users,
> and not one just negligent operators run into (we want people to upgrade
> OS versions), I think we ought to factor that into our decision what to
> do.
>
Hi,
this is an open item for release 14 . The discussion seems to have gone
silent for a couple of weeks. Are we in a position to make any
decisions? I hear what Andres says, but is anyone acting on it?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-05-05 21:09:47 | cache lookup failed for statistics object 123 |
Previous Message | Stephen Frost | 2021-05-05 20:53:01 | Re: .ready and .done files considered harmful |