Re: \dS and \df <pattern> crashing psql

On Thu, 25 May 2000, Tom Lane wrote:

>
> Hmm, news to us. It may be a platform-specific problem, so yes please
> do send a backtrace.
>

CAVEAT: I may just be missing something really obvious.

A high-level description of the problem is: If postmaster is started
with LC_COLLATE set to en_US in the db superuser's environment, then
working on a db created with createdb -E LATIN1 <foo> causes strange
behaviour in regexps. If that sounds like an obviously wrong use
of locale settings, you probably don't need to read any further, but
just tell me what's going on.

To replicate the problem, you need to do the following. All actions
are performed by postgres, the db superuser account

Install postgres 7.0 with all three of --enable-locale, --enable-recode,
and --enable-multibyte specified. Set the user postgres's LC_COLLATE env
var to any of the en_* locales available on your machine /except/
en_US.UTF-8, which doesn't seem to cause problems. The other locale vars
appear to be irrelevant; LC_COLLATE alone will do for replication. These
were my settings:

> locale
LANG=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE=en_US
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=

What follows are the operations I performed to get psql to crash:

> createdb -E LATIN1 foo
CREATE DATABASE
> psql foo
Welcome to psql, the PostgreSQL interactive terminal.
<snip>
foo=# create table TenChrName ( somelongname varchar (100) unique);
NOTICE: CREATE TABLE/UNIQUE will create implicit index
'tenchrname_somelongname_key' for table 'tenchrname'
CREATE
foo=# vacuum analyze;
VACUUM
foo=# \dS
The connection to the server was lost. Attempting reset: Failed.
!# \q
> kill `cat postmaster.pid`
> gdb postgres
<snip>
(gdb) run foo

/* note: the following query is the smallest part of \dS's expansion
* that is sufficient for a crash
*/
backend> select * from pg_class where relname ~ '^n';
ERROR: expression_tree_walker: Unexpected node type 0
ERROR: expression_tree_walker: Unexpected node type 0
backend> select * from pg_class where relname ~ '^n';
NOTICE: PortalHeapMemoryFree: 0x51c330 not in alloc set!
NOTICE: PortalHeapMemoryFree: 0x51c330 not in alloc set!

Program received signal SIGBUS, Bus error.
0x21ddf4 in AllocSetAlloc (set=0x500ff8, size=12) at aset.c:233
233 if (chunk->size >= size)
(gdb) bt
#0 0x21ddf4 in AllocSetAlloc (set=0x500ff8, size=12) at aset.c:233
#1 0x21f8a0 in PortalHeapMemoryAlloc (this=0x2bddc0, size=12)
at portalmem.c:253
#2 0x21ed20 in MemoryContextAlloc (context=0x2bddc0, size=12) at
mcxt.c:224
#3 0x126e84 in newNode (size=12, tag=T_List) at nodes.c:38
#4 0x127180 in lcons (obj=0x51a240, list=0x0) at list.c:112
#5 0x127220 in lappend (list=0x0, obj=0x51a240) at list.c:144
#6 0x14e6f8 in get_actual_clauses (restrictinfo_list=0x51a298)
at restrictinfo.c:55
#7 0x144b80 in create_scan_node (root=0x5134f8, best_path=0x51be80,
tlist=0x51b0b0) at createplan.c:152
#8 0x144ab0 in create_plan (root=0x5134f8, best_path=0x51be80)
at createplan.c:103
#9 0x147698 in subplanner (root=0x5134f8, flat_tlist=0x51a4a0,
qual=0x51a280, tuple_fraction=0) at planmain.c:288
#10 0x14740c in query_planner (root=0x5134f8, tlist=0x519b08,
qual=0x51a280,
tuple_fraction=0) at planmain.c:128
#11 0x14817c in union_planner (parse=0x5134f8, tuple_fraction=0)
at planner.c:530
#12 0x147b38 in subquery_planner (parse=0x5134f8, tuple_fraction=-1)
at planner.c:202
#13 0x147810 in planner (parse=0x5134f8) at planner.c:67
#14 0x1977c0 in pg_plan_query (querytree=0x5134f8) at postgres.c:512
#15 0x197a9c in pg_exec_query_dest (
query_string=0x2ba070 "select * from pg_class where relname ~ '^n';
\n",
dest=Debug, aclOverride=0 '\000') at postgres.c:646
#16 0x1978e4 in pg_exec_query (
query_string=0x2ba070 "select * from pg_class where relname ~ '^n';
\n")
at postgres.c:562
#17 0x1996f4 in PostgresMain (argc=2, argv=0xeffffa64, real_argc=2,
real_argv=0xeffffa64) at postgres.c:1590
#18 0x1026d0 in main (argc=2, argv=0xeffffa64) at main.c:103

If you actually care to go through the steps above, don't leave
anything out. The vacuum analyze serves no useful purpose, but you
won't get a crash if you omit it. The table indentifiers really
do need to be around 10 chars long. The regexp needs to match the
front of a string, so use '^foo' -- I couldn't get a crash with other
types of regexps but then I didn't try too many.

With the local settings described above, a query on pg_proc of the type
"select * from pg_proc where proname ~ '^n';" will /always/ produce the
following kind of error: "NOTICE: PortalHeapMemoryFree: <addr> not in
alloc set!" before printing the result (it never causes a crash, AFAICT,
and always does produce a correct result). You can get this behaviour
just by connecting to template1; perhaps other tables with bytea fields
may also do this, but pg_proc does it every single time. If you like, I'll
do a backtrace from where it produces that error, but this message is
getting too long for that.

If someone can replicate this (or even try and fail), it would help me
to learn whether the error lies in Postgres, Solaris's locales, or
yours truly. It seems too quirky to be a genuine bug.

Thanks, and let me know if you have any ideas.

Nishad