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

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

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 20:00:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 2013-01-08 14:53:29 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2013-01-08 14:28:14 -0500, Tom Lane wrote:
> >> I'm 100% unimpressed with making relpathbackend return a pointer to a
> >> static buffer.  Who's to say whether that won't create bugs due to
> >> overlapping usages?
> > I say it ;). I've gone through all callers and checked. Not that that
> > guarantees anything, but ...
> Even if you've proven it safe today, it seems unnecessarily fragile.
> Just about any other place we've used a static result buffer, we've
> regretted it, unless the use cases were *very* narrow.

Hm, relpathbackend seems pretty narrow to me.

Funny, we both argued the other way round than we are now when talking
about the sprintf(..., "%X/%X", (uint32)(recptr >> 32), (uint32)recptr)
thingy ;)

> > The reason a static buffer is better is that some of the *desc routines
> > use relpathbackend() and pfree() the result. That would require
> > providing a stub pfree() in xlogdump which seems to be exceedingly ugly.
> Why?  If we have palloc support how hard can it be to map pfree to free?
> And why wouldn't we want to?  I can hardly imagine providing only palloc
> and not pfree support.

Uhm, we don't have & need palloc support and I don't think
relpathbackend() is a good justification for adding it.


Andres Freund

 Andres Freund	         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: jamesDate: 2013-01-08 20:07:12
Subject: Re: json api WIP patch
Previous:From: David FetterDate: 2013-01-08 19:53:38
Subject: Re: Cascading replication: should we detect/prevent cycles?

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