FAQ
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
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

Here are the log entries:

TRAP: FailedAssertion("!(var->vartypmod == att_tup->atttypmod)", File: "execScan.c", Line: 220)
<2005-05-29 09:14:54 MDT 11356> LOG: server process (PID 17300) was terminated by signal 6
<2005-05-29 09:14:54 MDT 11356> LOG: terminating any other active server processes

Search Discussions

  • Tom Lane at May 29, 2005 at 5:20 pm

    Michael Fuhr 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
  • Mark Kirkwood at May 30, 2005 at 4:19 am

    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 at May 30, 2005 at 9:53 pm

    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 at May 30, 2005 at 11:27 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 29, '05 at 3:20p
activeMay 30, '05 at 11:27p
posts5
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase