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 3F04A535B9 for ; Wed, 30 Mar 2005 10:07:43 +0100 (BST) 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 04076-07 for ; Wed, 30 Mar 2005 09:07:40 +0000 (GMT) Received: from superfly.archi-me-des.de (superfly.archi-me-des.de [62.8.212.177]) by svr1.postgresql.org (Postfix) with ESMTP id 891225334D for ; Wed, 30 Mar 2005 10:07:37 +0100 (BST) Received: from superfly.archi-me-des.de (localhost [127.0.0.1]) by superfly.archi-me-des.de (8.12.3/8.12.3) with ESMTP id j2U97Xqa010814 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 30 Mar 2005 11:07:33 +0200 Received: (from frank@localhost) by superfly.archi-me-des.de (8.12.3/8.12.3/Debian-7.1) id j2U97WCT010812 for pgsql-sql@postgresql.org; Wed, 30 Mar 2005 11:07:32 +0200 From: frank@joerdens.de Date: Wed, 30 Mar 2005 11:07:32 +0200 To: pgsql-sql@postgresql.org Subject: can you change an FK constraint from NOT DEFERRABLE to DEFERRABLE Message-ID: <20050330090732.GA10376@mail.archi-me-des.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Subliminal-Message: Use Linux! Use Linux! X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.178 tagged_above=0 required=5 tests=NO_REAL_NAME X-Spam-Level: X-Archive-Number: 200503/384 X-Sequence-Number: 20863 Hello. Is it possible to change an FK constraint from NOT DEFERRABLE (the default) to DEFERRABLE without dropping and re-creating it? One idea that came up was to create a parallel set of constraints which perform the same checks as the existing ones as DEFERRABLE (and then drop the old set), but the objection there was that it'd lock the tables during the initial check. We're having a fairly serious deadlock issue and the thinking goes that Tom's suggestion here http://www.webservertalk.com/archive139-2004-8-364172.html to defer FK checks until transaction commit would maybe help. Right now we can't try this because all the FK checks where created with default settings. We'd like to avoid taking the database down for recreating foreign keys. Regards, Frank