X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 4DF679DC809 for ; Wed, 1 Feb 2006 11:20:20 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 66316-02 for ; Wed, 1 Feb 2006 11:20:24 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id ACEEC9DC803 for ; Wed, 1 Feb 2006 11:20:16 -0400 (AST) 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 k11FKLlu000308; Wed, 1 Feb 2006 10:20:21 -0500 (EST) To: "Marc Morin" cc: pgsql-performance@postgresql.org Subject: Re: partitioning and locking problems In-reply-to: <2BCEB9A37A4D354AA276774EE13FB8C263B3E5@mailserver.sandvine.com> References: <2BCEB9A37A4D354AA276774EE13FB8C263B3E5@mailserver.sandvine.com> Comments: In-reply-to "Marc Morin" message dated "Wed, 01 Feb 2006 09:25:10 -0500" Date: Wed, 01 Feb 2006 10:20:21 -0500 Message-ID: <307.1138807221@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.102 required=5 tests=[AWL=0.102] X-Spam-Score: 0.102 X-Spam-Level: X-Archive-Number: 200602/13 X-Sequence-Number: 16999 "Marc Morin" writes: > Do you mean it would be impossible to change the code so that existing > selects continue to use the pre-truncated table until they commit? Yes, because that table won't exist any more (as in the file's been unlinked) once the TRUNCATE commits. > The update/insert rule change appears to be more more doable? No? You've still got race conditions there: do onlooker transactions see the old set of rules, or the new set, or some unholy mixture? Removing the lock as you suggest would make it possible for the rule rewriter to pick up non-self-consistent data from the system catalogs, leading to arbitrarily bad behavior ... if you're lucky, it'll just crash, if you're not lucky the incorrect rule will do a fandango on your data. regards, tom lane