Re: pg_shmem_allocations view

On Mon, May 5, 2014 at 6:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, May 5, 2014 at 3:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> And the controlled shared segment is likely to be how big exactly? It's
>>> probably not even possible for it to be smaller than a page size, 4K or
>>> so depending on the OS. I agree with Andres that a name would be a good
>>> idea; complaining about the space needed to hold it is penny-wise and
>>> pound-foolish.
>> ...
>> Now, all that having been said, I recognize that human-readable names
>> are a generally useful thing, so I'm not going to hold my breath until
>> I turn blue if other people really want this, and it may turn out to
>> be useful someday. But if anyone is curious whether I'm *confident*
>> that it will be useful someday: at this point, no.
>
> I'm not confident that it'll be useful either. But I am confident that
> if we don't put it in now, and decide we want it later, there will be
> complaints when we change the API. Better to have an ignored parameter
> than no parameter.

I'm generally skeptical of that philosophy. If we put in an ignored
parameter, people may pass pointers to NULL or to garbage or to an
overly-long string, and they won't know it's broken until we make it
do something; at which point their code will begin to fail without
warning. Speaking as an employee of a company that maintains several
PostgreSQL extensions that sometimes need to be updated for newer
server versions, I'd rather have a clean API break that makes the
build fail than a "soft" break that supposedly lets things continue
working but maybe breaks them in subtler ways. Another problem with
this idea is that we might never get around to making it do anything,
and then the dead parameter is just a stupid and unnecessary wart.

If we're going to do anything at all here for 9.4, I recommend
ignoring the fact we're in feature freeze and going whole hog: add the
name, add the monitoring view, and add the monitoring view for the
main shared memory segment just for good measure. That way, if we get
the design wrong or something, we have a chance of getting some
feedback. If we're not going to do that, then I vote for doing
nothing and considering later whether to break it for 9.5, by which
time we may have some evidence as to whether and how this code is
really being used. Anyone who expects PostgreSQL's C API to be
completely stable is going to be regularly disappointed, as most
recently demonstrated by the Enormous Header Churn of the 9.3 era. I
don't particularly mind being the cause of further disappointment; as
long as the breakage is obvious rather than subtle, the fix usually
takes about 10 minutes.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company