Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tYnpt-00FOw0-0O for pgsql-general@arkaria.postgresql.org; Fri, 17 Jan 2025 15:00:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tYnpq-00HVRA-Di for pgsql-general@arkaria.postgresql.org; Fri, 17 Jan 2025 15:00:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tYnpq-00HVQy-2b for pgsql-general@lists.postgresql.org; Fri, 17 Jan 2025 15:00:34 +0000 Received: from mail-oo1-xc2f.google.com ([2607:f8b0:4864:20::c2f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tYnpo-0002Q5-1D for pgsql-general@postgresql.org; Fri, 17 Jan 2025 15:00:33 +0000 Received: by mail-oo1-xc2f.google.com with SMTP id 006d021491bc7-5f2e13cb359so635546eaf.3 for ; Fri, 17 Jan 2025 07:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737126031; x=1737730831; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=owRgIdYnycNxZ8ysKqDcKHsfwsO6z0BZFyBupdcLIGY=; b=b/5mCgRibxctb/Kp3pz8fCEibGpkTIH7J6+Q0inLLfbzVQlOfcBPur5bmzJUptNR4e VshGup+BrpwiZY2vg8qfKJo4CJtxPxSEo4f896rsM249r2c35KdKKhpYUo8N62IHvgxW akAJ5Ffd6GkDkMqzUOrc5SrwpQgWYHGhgEOjjPfmS1TPWZat+ZtzyHe9tcoL0MTInrZF LWj8VwYSiNjOUlMvA5oYzhqutH/x0P5oH3FYPEd0MvAeiXxFAFXpm09Zn5Ybv6Epzyao bJyIkiPQwzsZj1XoPn11uE3TwFZM74rj6nI1x2IXppMGYjR/R5mV0AdjdW3lEX+RdUxx SX1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737126031; x=1737730831; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=owRgIdYnycNxZ8ysKqDcKHsfwsO6z0BZFyBupdcLIGY=; b=jGTWzHYhz/yukhdRlCLXRm20mvgOTQHAvb5ngh0CMg6qmsOq5FiH+/AfX9iBqm3CHT nAbzVbI7ZY/2c76L3/sDmnfXr4qjkXRYaAE+hSGi2CJbGt1Y/zTwzI0Z3Pnnq9AH27sL 8kCX16Gf+0iF0Gm6TuA9dPxFMFK0ZOGv8XkDY7KyccupiO6+12dhXw+H0eZzmotZbl5B 4cg21SDGVR1Y0lcgEEBuQNUeL9SKIWcGyAyBsVfC7tTBYallqQiJ4v8ZV+r54msJfoRY 5XG+p3EpOtrLFnEexReoglW0IhpfRwvfuguoG/hnP6I+fU1mEDZ87B0snIWWN/1Hz9tJ oN4w== X-Gm-Message-State: AOJu0Yyc+W3eg31FcBwOqg07m+jt8jVsKjM+SRoVW0/WYczf5V0g6Nb0 +QPEWcliTej50GSvG02Ln6tcCDDu0kwsULGWF3p9FUaRbRLPVCwra8B1jkZUUNjQ2eGrjRvCt8u Vji0KCiCFy2gO1fkb9I6g/y8fU5/w2iCO X-Gm-Gg: ASbGnctcMLbkb/7UjkD1dRxuhYRvZovouXqoBy2izLW2XiE5AdHxAahWI42OXbB+xOR /gR1ZJ0uNDyxN9FTRCXm/TGQK24xNSEeU8KrF/oLy3pJqpkmZKpe3Ep0AYbYMBDqX1DMWdrTo X-Google-Smtp-Source: AGHT+IFmjks2deOjvB9fxQ59+x9NNbMqZWRR0i2mskLh5/3VHV6saW/p4UaVYoMzmfpMKRGcMFPqaSQglt+hJY/NgC0= X-Received: by 2002:a05:6871:5e15:b0:29e:5c94:5afd with SMTP id 586e51a60fabf-2b1c099e645mr1732428fac.1.1737126031121; Fri, 17 Jan 2025 07:00:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Fri, 17 Jan 2025 10:00:20 -0500 X-Gm-Features: AbW1kvZSqY3biXmrkIYhgGqpIDDE2PoFRpdJa6IrwZfMvSfZVWRMsrMjxRluEHY Message-ID: Subject: Re: glibc 2.35-2.39 upgrade requirements To: pgsql-general Content-Type: multipart/alternative; boundary="00000000000003e99f062be82c32" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000003e99f062be82c32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 17, 2025 at 1:12=E2=80=AFAM Kamen Kalchev wrote: > Hi everyone, we're planning to upgrade the OS running Postgres from ubunt= u > jammy to ubuntu noble. As part of the OS change, the glibc version will b= e > changed from glibc 2.35 to glibc 2.39.. > > Can someone confirm if changing the glibc between those versions will > require a full reindex of the Postgres cluster? > You never have to reindex _everything_. Only (for some definition of "only") indices with text/char/varchar/name columns need to be rebuilt. This is how I find such indices: create or replace view dba.all_indices_types as select tbcl.relnamespace::regnamespace::text||'.'||tbcl.relname as table_name , ndcl.relname as index_name , array_agg(ty.typname order by att.attnum) as index_types from pg_class ndcl inner join pg_index nd on (ndcl.oid =3D nd.indexrelid and ndcl.relkind in ('i', 'I') inner join pg_class tbcl on (nd.indrelid =3D tbcl.oid and tbcl.relkind in ('r', 'R', 'm'= )) inner join pg_attribute att on att.attrelid =3D nd.indexrelid inner join pg_type ty on att.atttypid =3D ty.oid where tbcl.relnamespace::regnamespace::text !=3D 'pg_catalog' group by tbcl.relnamespace::regnamespace::text||'.'||tbcl.relname , ndcl.relname order by 1, 2; select * from dba.all_indices_types where index_types && '{"text","varchar","char","text"}'; --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --00000000000003e99f062be82c32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 17, 2025 at 1:12=E2=80=AFAM K= amen Kalchev <kalchev035@gmail.c= om> wrote:
Hi everyone, we're planning to upgrade the O= S running Postgres from ubuntu jammy to ubuntu noble. As part of the OS cha= nge, the glibc version will be changed from glibc 2.35 to glibc 2.39..=C2=A0

Can someone confirm if changing the glibc between tho= se versions will require a full reindex of the Postgres cluster?=C2= =A0

<= div>You never have to reindex _everything_.=C2=A0 Only (for some definition= of "only") indices with text/char/varchar/name columns need to b= e rebuilt.

This is how I find such indices:
<= div>create or replace view dba.all_indices_types a= s
=C2=A0 =C2=A0 select tbcl.relnamespace::regnamespace::text||'.'= ;||tbcl.relname as table_name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = , ndcl.relname as index_name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ,= array_agg(ty.typname order by att.attnum) as index_types
=C2=A0 =C2=A0 = from pg_class ndcl
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inner join pg_index nd=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 on (ndcl.oid =3D nd.indexrelid a= nd ndcl.relkind in ('i', 'I')
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 inner join pg_class tbcl
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 o= n (nd.indrelid =3D tbcl.oid and tbcl.relkind in ('r', 'R', = 'm'))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inner join pg_attribute att=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 on att.attrelid =3D nd.indexreli= d
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inner join pg_type ty
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 on att.atttypid =3D ty.oid
=C2=A0 =C2=A0 where = tbcl.relnamespace::regnamespace::text !=3D 'pg_catalog'
=C2=A0 = =C2=A0 group by tbcl.relnamespace::regnamespace::text||'.'||tbcl.re= lname
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 , ndcl.relname
=C2=A0= =C2=A0 order by 1, 2;
select= * from dba.all_indices_types where index_types && '{"text= ","varchar","char","text"}';<= /div>


-= -
De= ath to <Redacted>, and butter sauce.
Don't boil me, I'm s= till alive.
<Redacted> lobster!
<= /div>
--00000000000003e99f062be82c32--