X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 2B9E28B9B6A for ; Tue, 22 Feb 2005 16:37:34 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 22738-05 for ; Tue, 22 Feb 2005 16:37:31 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id A01C68B9B31 for ; Tue, 22 Feb 2005 16:37:31 +0000 (GMT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j1MGbUka010244; Tue, 22 Feb 2005 11:37:30 -0500 (EST) To: pginfo Cc: Richard_D_Levine@raytheon.com, Michael Glaesemann , pgsql-sql@postgresql.org Subject: Re: pg primary key bug? In-reply-to: <421AFC7F.406@t1.unisoftbg.com> References: <4214B466.20908@t1.unisoftbg.com> <8125.1108661189@sss.pgh.pa.us> <4214C94F.2050806@t1.unisoftbg.com> <9340.1108664352@sss.pgh.pa.us> <4214D5C3.4070107@t1.unisoftbg.com> <9785.1108666900@sss.pgh.pa.us> <421992FE.3030108@t1.unisoftbg.com> <3293.1109026294@sss.pgh.pa.us> <421AC251.7060806@t1.unisoftbg.com> <7012.1109061770@sss.pgh.pa.us> <421AFC7F.406@t1.unisoftbg.com> Comments: In-reply-to pginfo message dated "Tue, 22 Feb 2005 10:33:51 +0100" Date: Tue, 22 Feb 2005 11:37:30 -0500 Message-ID: <10243.1109090250@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200502/243 X-Sequence-Number: 20354 pginfo writes: > You idea was that we have "vacuum full" + update or select for update in > the same time. > I think it is not the case, because we start vacuum full at 1:00 AM and > no one is working in this time. Hmm. AFAICT the duplicate row copies could only be produced by vacuum full, so that's certainly part of the issue. But if vacuum full in isolation were broken, we'd surely know it; so there must be some other contributing factor involved that your setup is exercising but other people are (mostly) not doing. I agree with the plan to use plain vacuum for awhile and see if that makes the problem go away. I think it would have to, but maybe I'm all wet about that. In the meantime I would suggest seeing if you can distill your application down into a test case that other people can run to reproduce the problem. It doesn't matter if the test doesn't make the bug happen very often, but we have to see the problem happening before we have much hope of fixing it. > Will vacuum full generate this problem if we have locked table in this > time? (It is possible to have locked table in theory) No, that's hardly likely. vacuum full deals with locks all the time. > Can you describe more detailed the idea of problem with "vacuum full" + > "update" and can some one make patch if this problem exists in theory > (if I understand you right)? I have no idea what the actual failure mechanism might be. regards, tom lane