In the current build on the anon cvs server, if I try to \d a table from
psql, the backend comes down.  I played with the query a bit and
discovered any query using '~' operator in the where clause on any table
(catalog or otherwise) causes an immediate backend crash.

Can anybody confirm that this is not happening on a win32/non-win32
build? (I had to change a couple of things to compile, just want to make
sure I didn't break anything). 

I did a make clean and a brand new initdb just to be safe.

Merlin


LOG:  statement: select * from pg_catalog.pg_class where relname ~
'test';
LOG:  server process (PID 4544) was terminated by signal 5
LOG:  terminating any other active server processes
WARNING:  terminating connection because of crash of another server
process
DETAIL:  The postmaster has commanded this server process to roll back
the current transaction and exit, because another server proc
ess exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and
repeat your command.
FATAL:  the database system is in recovery mode
LOG:  all server processes terminated; reinitializing
LOG:  database system was interrupted at 2004-05-21 11:22:35 Eastern
Daylight Time
LOG:  checkpoint record is at 0/EEC050
LOG:  redo record is at 0/EEC050; undo record is at 0/0; shutdown TRUE
LOG:  next transaction ID: 7678; next OID: 33592
LOG:  database system was not properly shut down; automatic recovery in
progress
LOG:  record with zero length at 0/EEC090
LOG:  redo is not required
LOG:  database system is ready
LOG:  statement: select * from chevy.cusfil limit 1;
LOG:  statement: select * from chevy.cusfil where cust_addr1 ~ 'test';
LOG:  server process (PID 5500) was terminated by signal 5
LOG:  terminating any other active server processes
WARNING:  terminating connection because of crash of another server
process
DETAIL:  The postmaster has commanded this server process to roll back
the current transaction and exit, because another server proc
ess exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and
repeat your command.

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html

Reply via email to