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 1sBano-0004wE-NY for pgsql-general@arkaria.postgresql.org; Mon, 27 May 2024 13:54:18 +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 1sBann-006kBK-SU for pgsql-general@arkaria.postgresql.org; Mon, 27 May 2024 13:54:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sBann-006kBC-HF for pgsql-general@lists.postgresql.org; Mon, 27 May 2024 13:54:15 +0000 Received: from uucp.dinoex.org ([2a0b:f840::12]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sBank-0011bX-KG for pgsql-general@lists.postgresql.org; Mon, 27 May 2024 13:54:14 +0000 Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]) by uucp.dinoex.org (8.18.1/8.18.1) with ESMTPS id 44RDs6Mv049699 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 27 May 2024 15:54:07 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) ARC-Seal: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1716818049; cv=none; b=TbpSo/KWpZHxrxMH0FGnP4Yg8e4R1FOrrlYTSaJLW0DsvH6MN1Y6dmvq9swkxIsXK5xpAtg3t7DH9pv7wK8iV/HU+Ua2RGkuGY3tRGVdooXpa/suC2ImLj02qN4PTGGP9BNz0R1zRmmD0amAMm2KblAiAoemLpopg2AWCss3dcw= ARC-Message-Signature: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1716818049; c=relaxed/simple; bh=9TOUA53UfzlQywcrJAb/Qvf52UCKqVa+rCeeDAb1zFs=; h=Received:Received:Received:Received:X-Authentication-Warning:Date: From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:X-Milter:X-Greylist; b=gZ6vpnJy48hnQsyBKyRAVmok1c/nuR0qonQh/EPBN7jBp+yusiPlLiWe031OYyrq5WJwtxrFm7QFKC9Q8I/2WXr6K0tRI98hHAh3ebYktLmyehLiAUUTxcAFg1Cq24ldgUp4b68aqdVn6qX3nEEGFpuHfndqj6cnGjpgO8VEW7o= ARC-Authentication-Results: i=1; uucp.dinoex.org Received: (from uucp@localhost) by uucp.dinoex.org (8.18.1/8.18.1/Submit) with UUCP id 44RDs6Co049698; Mon, 27 May 2024 15:54:06 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (disp-e.intra.daemon.contact [IPv6:fd00:0:0:0:0:0:0:112]) by admn.intra.daemon.contact (8.18.1/8.18.1) with ESMTPS id 44RDpfvR040002 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Mon, 27 May 2024 15:51:41 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (localhost [127.0.0.1]) by disp.intra.daemon.contact (8.18.1/8.18.1) with ESMTPS id 44RDnc1o008489 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 27 May 2024 15:49:39 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: (from pmc@localhost) by disp.intra.daemon.contact (8.18.1/8.18.1/Submit) id 44RDncAA008488; Mon, 27 May 2024 15:49:38 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: disp.intra.daemon.contact: pmc set sender to pmc@citylink.dinoex.sub.org using -f Date: Mon, 27 May 2024 15:49:38 +0200 From: Peter To: Laurenz Albe Cc: pgsql-general@lists.postgresql.org Subject: Re: Autovacuum endless loop in heap_page_prune()? Message-ID: References: <34f2beb882d607b360dea53433f95a767d1cad8f.camel@cybertec.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Milter: Spamilter (Reciever: uucp.dinoex.org; Sender-ip: 0:0:2a0b:f840::; Sender-helo: uucp.dinoex.org;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]); Mon, 27 May 2024 15:54:09 +0200 (CEST) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, May 27, 2024 at 01:51:56PM +0200, Laurenz Albe wrote: ! > ! Apart from hardware problems, one frequent cause is upgrading glibc ! > ! (if the index on a string column or expression). ! > ! > No, this is FreeBSD, we don't normally do such things... ;) ! ! You don't update the C library, or collations never change? I rarely update the C library. Kernel + libraries + OS programs are a single unit here, updated about once a year, and then by many people and with all the usual testing. I could lookup how often some locale was modified, but honestly, I'm too lazy now. | (but of course SQL_ASCII is a mistake). Really? I re-read the chapter on Locale/CharSet Support, and I don't see the mistake. Only one can not convert that to anything else, which is fine in this usecase (storing arbitrary filenames from any OS in any character-set within the same column). regards, PMc