On 2013-02-06 15:51:15 -0300, Alvaro Herrera wrote:
> Okay, here's an attempt at doing it that way. Notably this creates
> libpgcommon, a static library, to be used by both frontend and backend.
> There's only a frontend file now (fe_memutils.c); the backend side of it
> is empty. I verified that the backend makefile rules work, but there's
> no attempt to link it into the backend. libpgcommon piggybacks on
> libpgport: for instance there is no separate submake-pgcommon rule on
> which to depend, or LDFLAGS additions and the like, I just appended it
> all to existing pgport rules. Duplicating it would be much more verbose
> and pointless; if we ever need to distinguish these two libs, that can
> easily be done.
Looks good to me.
Although I have to admit I am wondering whether there still is a point
in using pg_malloc() et al. instead of just using palloc() et al. There
doesn't seem to be too much gained by that. But thats probably better
done as another patch ontop of this if at all.
> Some existing pg_malloc() implementations tried to do something other
> than exit(EXIT_FAILURE); pg_upgrade did pg_log(FATAL) for instance. But
> I don't think there is much point in that, so I've just made them all
> use fprintf(stderr); exit(EXIT_FAILURE); This is the same approach
> Zoltan ended up with in his patch.
If anything it should be plain write()s, as that wouldn't allocate
memory... But otherwise I aggree.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services