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