Your name : Nishad Prakash
Your email address : prakashn@uci.edu
System Configuration
---------------------
Architecture (example: Intel Pentium) : Sun Sparc
Operating System (example: Linux 2.0.26 ELF) : Solaris 2.6
PostgreSQL version (example: PostgreSQL-6.5.1): PostgreSQL-7.0
Compiler used (example: gcc 2.8.0) : gcc 2.95.2
Please enter a FULL description of your problem:
------------------------------------------------
In psql, when connected to template1 as the postgres superuser, the
\df function complains about some memory allocation problem. See the
following four examples for representative errors:
template1=# \df get
ERROR: AllocSetFree: cannot find block containing chunk
template1=# \df get
NOTICE: PortalHeapMemoryFree: 0x31f5b0 not in alloc set!
List of functions
Result | Function | Arguments
--------+---------------------+-------------
int4 | get_bit | bytea int4
int4 | get_byte | bytea int4
name | getdatabaseencoding |
name | getpgusername |
(4 rows)
template1=# \df get
NOTICE: PortalHeapMemoryFree: 0x344350 not in alloc set!
ERROR: AllocSetFree: cannot find block containing chunk
template1=# \df get
ERROR: SearchSysCache: recursive use of cache 2
Note that this is before creating any of my own databases -- at the
time when I got these errors I had just finished the installation.
There is another problem with the \d family. I created a new db
(named can) and its tables. Then, typing \dS has the following
effect:
can=# \dS
The connection to the server was lost. Attempting reset: Failed.
!# \d
You are currently not connected to a database.
!# \c can
No Postgres username specified in startup packet.
Segmentation fault
Note that this happens whether or not the tables are actually
populated; I ran a vacuum right after both acts (creation and
population) and \dS caused a crash out of psql each time.
FWIW, my 6.5.3 installation with the same configure and build
parameters, same data, etc. ran with no problems at all. Has anyone
had similar problems with the \d functions in 7.0?
Nishad