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 28CA69FB382
	for <pgsql-hackers-postgresql.org@postgresql.org>;
	Mon, 14 Aug 2006 04:41:59 -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 84278-09 for
	<pgsql-hackers-postgresql.org@postgresql.org>;
	Mon, 14 Aug 2006 07:41:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from svana.org (svana.org [125.62.87.134])
	by postgresql.org (Postfix) with ESMTP id 2CCD89FB381
	for <pgsql-hackers@postgresql.org>;
	Mon, 14 Aug 2006 04:41:55 -0300 (ADT)
Received: from kleptog by svana.org with local (Exim 4.50)
	id 1GCX54-00038x-Tf; Mon, 14 Aug 2006 17:41:50 +1000
Date: Mon, 14 Aug 2006 09:41:50 +0200
From: Martijn van Oosterhout <kleptog@svana.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Google SoC--Idea Request
Message-ID: <20060814074150.GA11315@svana.org>
Reply-To: Martijn van Oosterhout <kleptog@svana.org>
References: <36e682920604151205i75a08030x7c05a6f52fccf095@mail.gmail.com>
	<AB8B2106-EA96-4577-845B-6604CC140AEC@pgedit.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>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e"
Content-Disposition: inline
In-Reply-To: <19168.1145548592@sss.pgh.pa.us>
X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6
X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522  48A7 6394 F08A 0DC6 7BE6
X-PGP-Key-URL: <http://svana.org/kleptog/0DC67BE6.pgp.asc>
User-Agent: Mutt/1.5.9i
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: kleptog@svana.org
X-SA-Exim-Scanned: No (on svana.org); SAEximRunCond expanded to false
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=
X-Spam-Level: 
X-Archive-Number: 200608/880
X-Sequence-Number: 88373


--cNdxnHkX5QqsyA0e
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 20, 2006 at 11:56:32AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > About the only thing in the backend I found interesting was this:
> > src/backend/utils/hash/dynahash.c function hash_create
>=20
> 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.

[re: failure to create hash in shared memory causes crash]

Any thoughts on this? Make it a TODO item, document it, or simply
ignore it?

Have a nicy day,
--=20
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to l=
itigate.

--cNdxnHkX5QqsyA0e
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFE4Ck+IB7bNG8LQkwRAr+WAJ9LZT5idtBunGchRIN5clqqg6MJjACfcjoH
P38qg6+YMlbxicB7qfvYvk8=
=9SLz
-----END PGP SIGNATURE-----

--cNdxnHkX5QqsyA0e--