palloc unification

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: palloc unification
Date: 2013-02-04 22:50:45
Message-ID: 20130204225045.GM4963@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

There was some discussion about unifying backend and frontend
code/headers for palloc et al, particularly so that programs that want
to mix both can be easily compiled; see
http://www.postgresql.org/message-id/20130118150629.GC29501@alap2.anarazel.de
for what I believe to be the latest and greatest patch in that area.
The good news from that patch is that there is a reported (small)
performance increase from the approach suggested there, on Intel and
non-Intel platforms. So it seems we're okay on that front.

On the source code organization front, however, I'm not too happy with
that particular proposal. There would be two files named palloc.h, for
one thing, and also the changes to utils/palloc.h leave way too much of
the backend-only implementation exposed to the frontend world.

I propose to have a new subdirectory src/include/shared, and two
header files:

src/include/utils/palloc.h (same as today)
src/include/shared/fe_memutils.h
(pg_malloc, pg_free, pg_strdup decls)

utils/palloc.h would be modified so that #ifdef FRONTEND, only the basic
function declarations (palloc, pfree, pstrdup, pnstrdup) are exposed;
frontend environment would be safe from CurrentMemoryContext etc.

The frontend (pg_malloc) function definitions would live somewhere in,
say, src/shared/fe_memutils.c. For the palloc() implementation, I think
we should create another file, so that frontend-only programs that do
not require those symbols (most of them) are not unnecessarily bloated.

Opinions on having a new subdir?
We could eventually move some stuff from timestamp.c in there, so that
pg_xlogdump could get timestamp_to_str from there; we could perhaps
remove the ecpg implementation of that as well and make it use this one.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Phil Sorber 2013-02-04 23:26:53 get_progname() should not be const char *?
Previous Message Tom Lane 2013-02-04 22:32:18 Re: issues with range types, btree_gist and constraints