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

Re: Misc. consequences of backend memory management changes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Misc. consequences of backend memory management changes
Date: 2000-06-29 18:30:07
Message-ID: 956.962303407@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> Will anyone object if I make CLOBBER_FREED_MEMORY defined by default
>> until 7.1 release is near?

> I've been thinking that we need a configure option for this sort of stuff,
> like

>    --enable-debug=memory,lock,foo,noipc

> which would result in

> #define MEMORY_DEBUG 1
> #define LOCK_DEBUG 1
> #define FOO_DEBUG 1
> #undef IPC_DEBUG

> Comments?

Not unreasonable, though it would tend to encourage use of short,
hard-to-understand names for debug options :-(.  We could live with
that as long as there were adequate documentation about what each
option does in config.h.in.

If you wanna do it then I'd suggest folding cassert into the same
mechanism.

Last night I rearranged config.h.in so that the configure-driven symbols
are more clearly separated from the non-configurable symbols, and I also
separated out the debug symbols from the feature/limit symbols.  Should
make a good starting point for seeing what needs to be dealt with.
Unfortunately the existing debug symbols were mostly undocumented, and
I didn't take the time to dig to see what they do ... if anything ...

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Stephan SzaboDate: 2000-06-29 18:40:13
Subject: Re: AW: Proposal: More flexible backup/restore via pg_dump
Previous:From: Scott WintersteinDate: 2000-06-29 17:42:53
Subject: database into website

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