X-Original-To: pgsql-hackers-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id DEC159FB223 for ; Mon, 14 Aug 2006 09:09:46 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 52446-03 for ; Mon, 14 Aug 2006 12:09:38 +0000 (UTC) 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 55E479F931A for ; Mon, 14 Aug 2006 09:09:38 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k7EC9atR022544; Mon, 14 Aug 2006 08:09:36 -0400 (EDT) To: Martijn van Oosterhout cc: pgsql-hackers@postgresql.org Subject: Re: Google SoC--Idea Request In-reply-to: <20060814074150.GA11315@svana.org> References: <36e682920604151205i75a08030x7c05a6f52fccf095@mail.gmail.com> <36e682920604190909p68649a35m1953a7b4262b8852@mail.gmail.com> <200604200851.25569.xzilla@users.sourceforge.net> <20060420140501.GB1984@svana.org> <18559.1145545471@sss.pgh.pa.us> <20060420154805.GD1984@svana.org> <19168.1145548592@sss.pgh.pa.us> <20060814074150.GA11315@svana.org> Comments: In-reply-to Martijn van Oosterhout message dated "Mon, 14 Aug 2006 09:41:50 +0200" Date: Mon, 14 Aug 2006 08:09:36 -0400 Message-ID: <22543.1155557376@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200608/884 X-Sequence-Number: 88377 Martijn van Oosterhout writes: > On Thu, Apr 20, 2006 at 11:56:32AM -0400, Tom Lane wrote: >> I wonder if we shouldn't just remove the hash_destroy calls in >> hash_create's failure paths. hash_destroy is explicitly not gonna >> work on a shared-memory hashtable, and in all other cases I'd expect >> that any already-allocated table structure will be in a palloc context >> that will get cleaned up during error recovery. > Any thoughts on this? Make it a TODO item, document it, or simply > ignore it? It's like a two-line patch, so hardly worth putting in TODO ... might as well just do it. IIRC the motivation is mostly to silence a Coverity warning? regards, tom lane