Re: pg_buffercache causes assertion failure

Michael Fuhr <mike@fuhr.org> writes:
> I'm not sure when this broke, but using contrib/pg_buffercache with
> the latest HEAD causes an assertion failure:

> test=# SELECT * FROM pg_buffercache;
> server closed the connection unexpectedly

Fixed; turns out to be an ancient parse-analysis bug that was causing
the view definition to not agree with the function definition if the
function definition included a nondefault typmod.

I wonder though why this contrib module is defining its output as
numeric(10) --- seems like a pretty inefficient choice compared to,
say, int8; or even int4 which is what the pg_locks view is using.

And it's arguably a wrong specification anyway, since the code is doing
nothing to enforce that precision.

Should tupledesc_match() in nodeFunctionscan.c be enforcing equality
of typmods?
        regards, tom lane