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

Re: pg_buffercache causes assertion failure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Fuhr <mike(at)fuhr(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org,Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
Subject: Re: pg_buffercache causes assertion failure
Date: 2005-05-29 17:19:24
Message-ID: 8759.1117387164@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Michael Fuhr <mike(at)fuhr(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-05-29 17:24:22
Subject: Re: Simplifying unknown-literal handling
Previous:From: Alvaro HerreraDate: 2005-05-29 17:13:55
Subject: Re: Simplifying unknown-literal handling

pgsql-patches by date

Next:From: Peter EisentrautDate: 2005-05-29 18:00:19
Subject: Re: Escape handling in COPY, strings, psql
Previous:From: Tom LaneDate: 2005-05-29 15:38:14
Subject: Re: skip FK trigger on UPDATE

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