Re: Google SoC--Idea Request

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Google SoC--Idea Request
Date: 2006-08-14 07:41:50
Message-ID: 20060814074150.GA11315@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 20, 2006 at 11:56:32AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > About the only thing in the backend I found interesting was this:
> > src/backend/utils/hash/dynahash.c function hash_create
>
> 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,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikolay Samokhvalov 2006-08-14 08:31:30 How to control the content of BKI files during installation process?
Previous Message Alvaro Herrera 2006-08-14 04:51:40 Re: pgstattuple extension for indexes