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 1p07hq-0001yh-Ug for pgsql-hackers@arkaria.postgresql.org; Tue, 29 Nov 2022 20:59:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p07hp-0002bv-Il for pgsql-hackers@arkaria.postgresql.org; Tue, 29 Nov 2022 20:59:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p07hp-0002bl-9X for pgsql-hackers@lists.postgresql.org; Tue, 29 Nov 2022 20:59:53 +0000 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p07hn-0007Ww-2Y for pgsql-hackers@postgresql.org; Tue, 29 Nov 2022 20:59:52 +0000 Received: by mail-pf1-x42e.google.com with SMTP id c15so5578035pfb.13 for ; Tue, 29 Nov 2022 12:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20210112.gappssmtp.com; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=ICEvZgWoH3UTRNI2P2iDwuKM/VXvLv3ATXdkfjN8nCE=; b=8LNXuQfUs+WDcYP8gAvO8G0CPktTG/XKl51fzWYqaLXY60DjcjENmtBaXp+r5CemAj KR+Sc6fLu+9dPthSvOirze3r7IhEh11BuY7tb9I+KS1467O7ZriJgM/2TablyNz721zp 1yX75tw5+ji5zvylmYDRuF2o3kcxxa2Z+HWUuSlC02plYJs6UL0moTukDiZ/9bXXamlK D/eQ/s+bJZZEsAEgCh3GNQVF7BDW1AQy6SvbTQ37+dBZK8EGR8TBFcu7JFy1A6RGHjGA TC/a2DKNycJ9GSzVZvSl3wiB0hROxyEjts/UAbZSGUKNHb2bGSehKNJpp2wBGDkxAdue W5kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ICEvZgWoH3UTRNI2P2iDwuKM/VXvLv3ATXdkfjN8nCE=; b=19HH2OrzgwvuBafC9Xttply89fYcGbi9Crcn0FJNp57gqbRgQB2ZHVuTVCxQ7OC1gE gcjh5OJJPT+JF/yCQBzE3XCekxcvVBnQ6nRI+GqakOjdxlRS3uM9Nh8HnpP0i74SPIPL Q6SNklv4ns8KCPUNLFf/M+0HyWi+/9o3GWBjzxsy7DD3HJFI4PVLM1i+oLmYudswsD5Z Hylk5elhW3r08wN4uSJWeAA+bm/LPKn11GPnKStTVyJA+RGxYiFMeCmeBCq76R8huMGf Y/hsy8Kz06yesG98HpAnU+9/GRG0FHjw4F5eAkeB00T33v3BHQxZMOfaBA9fecFwSf+E 3nTg== X-Gm-Message-State: ANoB5pl9g3gp82TcWBxjAS5dNIvoxbZOOrqhcqN+Do2AuqV0S8x4SzGw 654Dbw7fBQchy/Sb6QF3Wq+4mQ== X-Google-Smtp-Source: AA0mqf5cQ6933kD1FVmy0bCGdqoRt0d7I7w/PCtsYzgJlyhTWSxHtu582yclxk7BjrSW1lLmVy4RbQ== X-Received: by 2002:a63:cf0e:0:b0:477:b603:f754 with SMTP id j14-20020a63cf0e000000b00477b603f754mr30632617pgg.232.1669755589984; Tue, 29 Nov 2022 12:59:49 -0800 (PST) Received: from jeff-laptop.lan (c-73-231-146-4.hsd1.ca.comcast.net. [73.231.146.4]) by smtp.gmail.com with ESMTPSA id e15-20020a17090301cf00b0018990ba4985sm3963206plh.272.2022.11.29.12.59.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Nov 2022 12:59:49 -0800 (PST) Message-ID: <12a7c9ddd5c44003869a114d0b5326fec27b2477.camel@j-davis.com> Subject: Re: Collation version tracking for macOS From: Jeff Davis To: Thomas Munro Cc: Jeremy Schneider , Peter Eisentraut , Peter Geoghegan , "Nasby, Jim" , Tom Lane , pgsql-hackers Date: Tue, 29 Nov 2022 12:59:47 -0800 In-Reply-To: References: <398aabd1-ad95-ba2d-d70a-dd5d90bf6e07@enterprisedb.com> <606bd2baa6d65b38fee6eb23bba40c5da210255b.camel@j-davis.com> <9f8e9b5a3352478d4cf7d6c0a5dd7e82496be4b6.camel@j-davis.com> <346f836208a39009c1998ed5a41c7f1a0be36911.camel@j-davis.com> <0f7922d4f411376f420ec9139febeae4cdc748a6.camel@j-davis.com> <331d8ffd-0bfa-9f5a-e1d1-23a242f44a27@ardentperf.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu1 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 2022-11-30 at 08:41 +1300, Thomas Munro wrote: > In terms of user experience, I think that might mean that users of > 'zh' who encounter warnings after a minor upgrade would therefore > really only have the options of REFRESHing and rebuilding, or > downgrading the package, because there's no way for us to access the > older version.=C2=A0 Users of 'en' probably only encounter collversion > changes when moving between OS releases with an ICU major version > change, and then the various schemes in this thread can help them > avoid the need to rebuild, until they eventually want to, if ever. I installed the first minor release for each major, and got some new tables. I think we can all agree that it's a lot easier to work with information once it's in table form. Here's what I found for the 'ar' locale (firstminor/lastminor are the icu library versions, firstcollversion/lastcollversion are their respective collation versions for the given locale): firstminor | lastminor | firstcollversion | lastcollversion=20 ------------+-----------+------------------+----------------- 60.1 | 60.3 | 153.80.32 | 153.80.32.1 64.1 | 64.2 | 153.96.35 | 153.97.35.8 68.1 | 68.2 | 153.14.38 | 153.14.38.8 (3 rows) For 'en': firstminor | lastminor | firstcollversion | lastcollversion=20 ------------+-----------+------------------+----------------- 64.1 | 64.2 | 153.96 | 153.97 (1 row) And for 'zh': firstminor | lastminor | firstcollversion | lastcollversion=20 ------------+-----------+------------------+----------------- 60.1 | 60.3 | 153.80.32 | 153.80.32.1 64.1 | 64.2 | 153.96.35 | 153.97.35.8 68.1 | 68.2 | 153.14.38 | 153.14.38.8 (3 rows) It looks like collation versions do change in minor releases. It looks like it's *not* safe to lock a collation to a major version *if* that major version could be updated to a new minor. And we can't lock to a minor, as I said earlier. Therefore, once we lock a collation down to a major release, we better keep that in the icu_library_path, and never touch it, and never install a new minor for that major. Then again, maybe some of these are just about how the version is reported... maybe 153.80.32 and 153.80.32.1 are really the same version? But 64.1 -> 64.2 looks like a real difference. I suppose the next step is to test with actual data and find differences? --=20 Jeff Davis PostgreSQL Contributor Team - AWS