Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nxCju-0006qn-4x for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jun 2022 19:13:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nxCjs-0007Yx-J5 for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jun 2022 19:13:40 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nxCjs-0007Yo-5B for pgsql-hackers@lists.postgresql.org; Fri, 03 Jun 2022 19:13:40 +0000 Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nxCjp-0006Ca-2w for pgsql-hackers@postgresql.org; Fri, 03 Jun 2022 19:13:39 +0000 Received: by mail-pj1-x102e.google.com with SMTP id gc3-20020a17090b310300b001e33092c737so7797551pjb.3 for ; Fri, 03 Jun 2022 12:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ardentperf-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=Op3Pk14iJFmJy6fB9iKhzBwgfiuTg8q3lFR0w0UTIWI=; b=IgvCfL+KQLxD3FXPzWXDotITrySsrYyieXHJSlr193iT/biqCqR5aXS9QNp55h1sqv BvHAXFvvSDQKFevJV3tRPGl0vFV00leJIlTdyQw2np77YmLIp8z21MVwQDot9KPHxBI3 /K3kxTdhZXGPn8i57qGIZC/CpPMLO7cbxPeD12CYO7RsGp+1wSGnmh7urbVYEij88bHC jNwRELre/MgrShrGZeeVKCEauA2M7UPMxIfYGJMy/hTDl53Iq+7ZXbzwxsJvretw2E8v q6GU/5wg6BpXmKVfrUBa1GY3DfHNT1NYbGlEl4xOhKStC7g4j/J3WzCsMkHhSM7Jhwbx U5zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Op3Pk14iJFmJy6fB9iKhzBwgfiuTg8q3lFR0w0UTIWI=; b=huEfzw89yf1mD0eMyMHa099SPDcU6LZ9H8P6Xye8KT4MiLl7TJ5uOfRxDzZbWfRPKE igUO8T2cUbYpbNg3J4m/laFmx3EexFH6pwfe/f/cut2Fjz6nwo512EBuua1ceb7R48BW nFI562ZszSfqk7b+kFY2U402De9yD85Xnfa9BAZSuGnaiG545MPIu0zCXqfjTkq39QK4 DqDMRwbvITv91JeyFKMqWm+24TTau+PTYiuRZvNbTRfN5c1/9G3SpjXY7zy++k4H8oks WX9j8VHWRMELTIYlAja6PseUVayKtLVlIFSAIQbzmZ1GZvzVHbXWIN5hFjm8+URYRkZQ QGQQ== X-Gm-Message-State: AOAM531jeB9iD9JiOLa+k8EzTiLzZEB0Tk0usbjucPrNkKpWMH1Xffzk fEy0NIfP/5ta+bH3je1kV2PzAg== X-Google-Smtp-Source: ABdhPJxNa/jaD1ZeW2+robCoFn073CLfnD1u9+b5M5xVC9O/wVCw5qRMW7sOvv2Pb+I9905snaV1ng== X-Received: by 2002:a17:90b:33cc:b0:1e8:5174:e1c2 with SMTP id lk12-20020a17090b33cc00b001e85174e1c2mr263514pjb.21.1654283614792; Fri, 03 Jun 2022 12:13:34 -0700 (PDT) Received: from [10.111.246.49] (54-240-196-174.amazon.com. [54.240.196.174]) by smtp.gmail.com with ESMTPSA id w22-20020a170902d71600b0015f4b7a012bsm5760392ply.251.2022.06.03.12.13.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Jun 2022 12:13:34 -0700 (PDT) Message-ID: <1874de62-6bec-4bc1-1d14-0a2730b125da@ardentperf.com> Date: Fri, 3 Jun 2022 12:13:33 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: Collation version tracking for macOS Content-Language: en-US To: Tom Lane , Peter Eisentraut Cc: Thomas Munro , pgsql-hackers References: <381977b1-0898-cb6f-a427-3b5d873e81bd@enterprisedb.com> <231072.1654273317@sss.pgh.pa.us> From: Jeremy Schneider In-Reply-To: <231072.1654273317@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 6/3/22 9:21 AM, Tom Lane wrote: > > According to that document, they changed it in macOS 11, which came out > a year and a half ago. Given the lack of complaints, it doesn't seem > like this is urgent enough to mandate a post-beta change that would > have lots of downside (namely, false-positive warnings for every other > macOS update). Sorry, I'm going to rant for a minute... it is my very strong opinion that using language like "false positive" here is misguided and dangerous. If new version of sort order is released, for example when they recently updated backwards-secondary sorting in french [CLDR-2905] or matching of v and w in swedish and finnish [CLDR-7088], it is very dangerous to use language like “false positive” to describe a database where there just didn't happen to be any rows with accented french characters at the point in time where PostgreSQL magically changed which version of sort order it was using from the 2010 french version to the 2020 french version. No other piece of software that calls itself a database would do what PostgreSQL is doing: just give users a "warning" after suddenly changing the sort order algorithm (most users won't even read warnings in their logs). Oracle, DB2, SQL Server and even MySQL carefully version collation data, hardcode a pseudo-linguistic collation into the DB (like PG does for timezones), and if they provide updates to linguistic sort order (from Unicode CLDR) then they allow the user to explicitly specify which version of french or german ICU sorting they are want to use. Different versions are treated as different sort orders; they are not conflated. I have personally seen PostgreSQL databases where an update to an old version of glibc was applied (I'm not even talking 2.28 here) and it resulted in data loss b/c crash recovery couldn't replay WAL records and the user had to do a PITR. That's aside from the more common issues of segfaults or duplicate records that violate unique constraints or wrong query results like missing data. And it's not just updates - people can set up a hot standby on a different version and see many of these problems too. Collation versioning absolutely must be first class and directly controlled by users, and it's very dangerous to allow users - at all - to take an index and then use a different version than what the index was built with. Not to mention all the other places in the DB where collation is used... partitioning, constraints, and any other place where persisted data can make an assumption about any sort of string comparison. It feels to me like we're still not really thinking clearly about this within the PG community, and that the seriousness of this issue is not fully understood. -Jeremy Schneider -- http://about.me/jeremy_schneider