Skip site navigation (1) Skip section navigation (2)

Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it
Date: 2013-01-08 23:23:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> And functions that return static buffers are evil incarnate.  I've
> spent way too much of my life dealing with the supreme idiocy that is
> fmtId().  If someone ever finds a way to make that go away, I will buy
> them a beverage of their choice at the next conference we're both at.

Yeah, that was exactly the case that was top-of-mind when I was
complaining about static return buffers upthread.

It's not hard to make the ugliness go away: just let it strdup its
return value.  The problem is that in the vast majority of usages it
wouldn't be convenient to free the result, so we'd have a good deal
of memory leakage.  What might be interesting is to instrument it to
see how much (adding a counter to the function ought to be easy enough)
and then find out whether it's an amount we still care about in 2013.
Frankly, pg_dump is a memory hog already - a few more identifier-sized
strings laying about might not matter anymore.

(Wanders away wondering how many relpathbackend callers bother to free
its result, and whether that matters either ...)

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-09 00:04:32
Subject: Re: Index build temp files
Previous:From: Bruce MomjianDate: 2013-01-08 22:48:55
Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group