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

Tom Lane wrote:

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.

I couldn't use int4 as the underlying datatype is unsigned int (not
available as exposed Pg type). However, using int8 sounds promising (is
int8 larger than unsigned int on 64-bit platforms?).

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

Hmmm - that's right, not sure why I did that :-( just using numeric in
the view might have been more sensible.

cheers

Mark

Mark Kirkwood wrote:

I couldn't use int4 as the underlying datatype is unsigned int (not
available as exposed Pg type). However, using int8 sounds promising (is
int8 larger than unsigned int on 64-bit platforms?).

Blocknumber is defined as uint32 in block.h - so should always be safe
to represent as an int8 I am thinking.

I will look at patching pg_buffercache, changing numeric -> int8 for the
relblocknumber column. This seems a tidier solution than using numeric,
and loses the numeric overhead.

regards

Mark

Mark Kirkwood wrote:

Mark Kirkwood wrote:

I couldn't use int4 as the underlying datatype is unsigned int (not
available as exposed Pg type). However, using int8 sounds promising
(is int8 larger than unsigned int on 64-bit platforms?).

Blocknumber is defined as uint32 in block.h - so should always be safe
to represent as an int8 I am thinking.

I will look at patching pg_buffercache, changing numeric -> int8 for the
relblocknumber column. This seems a tidier solution than using numeric,
and loses the numeric overhead.

This patch changes the use of numeric to int8 to represent the
relblocknumber column.

regards

Mark

Mark Kirkwood <markir@paradise.net.nz> writes:

This patch changes the use of numeric to int8 to represent the
relblocknumber column.

Applied, thanks.

regards, tom lane

Tom Lane wrote:

Mark Kirkwood <markir@paradise.net.nz> writes:

This patch changes the use of numeric to int8 to represent the
relblocknumber column.

Applied, thanks.

This reminds me:

I did some patches for 7.4 and 8.0 a while ago (attached) - while I do
not expect these to be applied (unless it's ok for contrib to get extra
modules in stable releases...), is there somewhere for things like this
to go?

cheers

Mark

P.s : They are amended to use int8 too :-)

On Tue, 2005-05-31 at 13:07 +1200, Mark Kirkwood wrote:

I did some patches for 7.4 and 8.0 a while ago (attached) - while I do
not expect these to be applied

Right, I don't see a need to backport this.

is there somewhere for things like this to go?

Pg Foundry?

-Neil

Neil Conway wrote:

On Tue, 2005-05-31 at 13:07 +1200, Mark Kirkwood wrote:

I did some patches for 7.4 and 8.0 a while ago (attached) - while I do
not expect these to be applied

Right, I don't see a need to backport this.

is there somewhere for things like this to go?

Pg Foundry?

Of course! Thanks

Mark