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 1ovhNE-0000k5-8J for pgsql-bugs@arkaria.postgresql.org; Thu, 17 Nov 2022 16:04:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ovhND-0001Vg-6Z for pgsql-bugs@arkaria.postgresql.org; Thu, 17 Nov 2022 16:04:19 +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 1ovhNC-0001VT-VL for pgsql-bugs@lists.postgresql.org; Thu, 17 Nov 2022 16:04:18 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ovhNA-00084G-Q8 for pgsql-bugs@lists.postgresql.org; Thu, 17 Nov 2022 16:04:17 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2AHG4Fln1834627; Thu, 17 Nov 2022 11:04:15 -0500 From: Tom Lane To: fredmw7@gmail.com cc: pgsql-bugs@lists.postgresql.org Subject: Re: Server table rows permanently fixed (cannot be deleted or truncated) In-reply-to: References: Comments: In-reply-to Fred Williams message dated "Thu, 17 Nov 2022 07:49:34 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1834625.1668701055.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2022 11:04:15 -0500 Message-ID: <1834626.1668701055@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Fred Williams writes: > I am unable to delete or edit a specific range of table rows (I'll call > them corrupted rows) for a specific primary key. If I truncate the entir= e > table, the corrupted rows remain. In the corrupted rows, I can successfu= lly > update non-primary key fields, but not primary-key fields. > *Miscellaneous* > 1. The problem does not occur on a test server using the same exact > table. > 2. If I rename the table, I can remove the corrupted rows and/or upda= te > the primary keys (such as changing the DateTime). However, when I ren= ame it > back, the corrupted rows reappear! TBH, I'm suspecting pilot error. I wonder whether you have another table by the same name in a different schema, which is the one containing the "corrupted" rows, and after you rename this table out of the way you're unintentionally accessing the other one. That theory doesn't explain the rows surviving TRUNCATE, but maybe inheritance could --- IIRC, TRUNCATE will not touch child tables. So maybe the alias table is also an inheritance child of the one you are modifying? This command in psql would clarify much: postgres=3D# \d+ *."NCAASchedule" regards, tom lane