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

Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>,Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Date: 2013-01-13 18:07:33
Message-ID: 20130113180733.GD26173@awork2.anarazel.de (view raw or flat)
Thread:
Lists: pgsql-hackers
On 2013-01-12 18:15:17 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2013-01-12 13:16:56 -0500, Tom Lane wrote:
> >> However, using a do-block with a local variable is definitely something
> >> worth considering.  I'm getting less enamored of the __builtin_constant_p
> >> idea after finding out that the gcc boys seem to have curious ideas
> >> about what its semantics ought to be:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=894515
> 
> > I wonder whether __builtin_choose_expr is any better?
> 
> Right offhand I don't see how that helps us.  AFAICS,
> __builtin_choose_expr is the same as x?y:z except that y and z are not
> required to have the same datatype, which is okay because they require
> the value of x to be determinable at compile time.  So we couldn't just
> write __builtin_choose_expr((elevel) >= ERROR, ...).  That would fail
> if elevel wasn't compile-time-constant.  We could conceivably do
> 
> __builtin_choose_expr(__builtin_constant_p(elevel) && (elevel) >= ERROR, ...)
> 
> with the idea of making real sure that that expression reduces to a
> compile time constant ... but stacking two nonstandard constructs on
> each other seems to me to probably increase our exposure to gcc's
> definitional randomness rather than reduce it.  I mean, if
> __builtin_constant_p can't already be trusted to act like a constant,
> why should we trust that __builtin_choose_expr doesn't also have a
> curious definition of constant-ness?

I was thinking of something like the above, yes. It seems to me to
generate code the compiler would need to really make sure the condition
in __builtin_choose_expr() is really constant, so I hoped the checks
inside are somewhat strict...

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2013-01-13 18:18:58
Subject: psql binary output
Previous:From: Andres FreundDate: 2013-01-13 18:02:47
Subject: Re: logical changeset generation v3 - comparison to Postgres-R change set format

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