| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Google SoC--Idea Request |
| Date: | 2006-08-14 12:09:36 |
| Message-ID: | 22543.1155557376@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-08-14 12:12:08 | Re: How to control the content of BKI files during installation process? |
| Previous Message | Tom Lane | 2006-08-14 11:58:12 | Re: pgstattuple extension for indexes |