~ crashes backend

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.