Hello,
My apologies if this is not a bug or has already been resolved. I have searched fairly extensively for this particular problem and haven't found anything yet.
I have been having problems with psql under linux lately and this problem has followed me from 7.4.4 - 7.4.6, but it started sometime after I upgraded to 7.4.4. I am running Gentoo linux on an Intel Xeon box using kernel 2.4.23. I think the problem has something to do with .psql_history. Here is the recreation scenario:
Step 1: Remove .psql_history from my home directory
Step 2: run psql, I connect successfully to the database, can change databases, can execute statements, examine tables, etc... everything works fine
Step 3: \q to exit psql and look at the history file, everything looks normal.
Step 4: run psql again, connection to the database takes 30-40 seconds
Step 5: \c to another database and I get this message connection pointer is NULL Previous connection kept
Step 6a: If I try to do a select statement from any table I get a Segmentation fault, now when I examine .psql_history I only see the commands from my previous session, I also get this message in the log "LOG: unexpected EOF on client connection"
Step 6b: If I try to do a \q to disconnect psql hangs for more than a minute, and pegs the processor at about 96% finally it drops me back to my shell, now when I examine .psql_history the file size has grown to 18 megabytes, and is full of empty space, other than the history data from my first session at the beginning of the file. There is no message in the log for this operation.
If I remove the .psql_history file again everything works fine for one session. Also, if as root I create a readonly .psql_history file for my current user the problem does not reappear. I have tested this with several users, all with the same results.
hexdump -C of the 18 megabyte .psql_history file looks like this:
00000000 5f 48 69 53 74 4f 72 59 5f 56 32 5f 0a 73 65 6c |_HiStOrY_V2_.sel| 00000010 65 63 74 5c 30 34 30 2a 5c 30 34 30 66 72 6f 6d |ect\040*\040from| 00000020 5c 30 34 30 73 74 61 74 65 73 3b 5c 30 31 32 0a |\040states;\012.| 00000030 5c 31 33 34 63 5c 30 34 30 73 6c 75 77 69 66 3b |\134c\040sluwif;| 00000040 5c 30 31 32 0a 73 65 6c 65 63 74 5c 30 34 30 2a |\012.select\040*| 00000050 5c 30 34 30 66 72 6f 6d 5c 30 34 30 73 74 61 74 |\040from\040stat| 00000060 65 73 3b 5c 30 31 32 0a 73 65 6c 65 63 74 5c 30 |es;\012.select\0| 00000070 34 30 2a 5c 30 34 30 66 72 6f 6d 5c 30 34 30 73 |40*\040from\040s| 00000080 74 61 74 65 3b 5c 30 31 32 0a 5c 31 33 34 71 5c |tate;\012.\134q\| 00000090 30 31 32 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a |012.............| 000000a0 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a |................| * 01178d50 0a 0a 0a 0a 0a 0a 5c 31 33 34 71 0a |......\134q.|
Also, pgadmin III and all of the applications connecting to the database work flawlessly from what I can tell. The only problem is with psql. Since this started happening a significant time after I upgraded to 7.4.4, and since it is immune to version upgrades I am thinking it may have something to do with one of the shared libraries that psql uses, but I really am not sure where to start looking.
TIA for the help.
Dave Wilde
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
