X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 1ADC99DC83A for ; Mon, 20 Mar 2006 14:13:53 -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 38639-01 for ; Mon, 20 Mar 2006 14:13:52 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from pih-relay04.plus.net (pih-relay04.plus.net [212.159.14.131]) by postgresql.org (Postfix) with ESMTP id C3BB39DCA55 for ; Mon, 20 Mar 2006 14:13:49 -0400 (AST) Received: from [213.162.97.75] (helo=mail.metronet.co.uk) by pih-relay04.plus.net with esmtp (Exim) id 1FLOt3-0007uc-NH; Mon, 20 Mar 2006 18:13:49 +0000 Received: from mainbox.archonet.com (84-51-143-99.archon037.adsl.metronet.co.uk [84.51.143.99]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP id C6650422929; Mon, 20 Mar 2006 17:30:43 +0000 (GMT) Received: from [192.168.1.17] (client17.office.archonet.com [192.168.1.17]) by mainbox.archonet.com (Postfix) with ESMTP id 8B888FF04; Mon, 20 Mar 2006 17:30:43 +0000 (GMT) Message-ID: <441EE6C3.3050300@archonet.com> Date: Mon, 20 Mar 2006 17:30:43 +0000 From: Richard Huxton User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Jeff Frost Cc: Tom Lane , pgsql-sql@postgresql.org Subject: Re: update before drop causes OID problems in transaction? References: <10754.1142635969@sss.pgh.pa.us> <13574.1142663266@sss.pgh.pa.us> <13832.1142664905@sss.pgh.pa.us> <441EB977.3000706@archonet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.124 required=5 tests=[AWL=0.124] X-Spam-Score: 0.124 X-Spam-Level: X-Archive-Number: 200603/314 X-Sequence-Number: 24660 Jeff Frost wrote: > >> Another problem might well be with your plpgsql trigger function. If >> you're dropping/re-creating credit_card_audit then that'll give you >> the error you're seeing. > > The trigger shouldn't be firing at all in this scenario as it is on > credit_card and not credit_card_audit. Are you saying that it could > cause this sort of problem even though it doesn't fire? Actually, my last reply isn't quite accurate. Looking at it, you do update "credit_card_audit" from within the trigger. So, it can cause a problem if called, but if it isn't called then it will not. -- Richard Huxton Archonet Ltd