[GENERAL] psql Segmentation fault
Since we converted to PG8, we've been experiencing segfaults when the psql client exits. It doesn't have any real effect on things... or it hasn't until now. RHEL4 i686 - PostgresQL 8.2.4 (non-redhat) -bash-3.00$ psql -n Welcome to psql 8.2.4, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# \q Segmentation fault That's what happens every time. No core file is produced. I've done some searches and discovered that this might be related to readline. But that doesn't seem right since it crashes when I run psql -n (no readline support). I've tried removing .psql_history files and even changing perms to prevent writes. Nothing seems to work. Now it's affecting pg_dumpall -g, which we use to backup all user accounts and roles. It seems to seqfault before it finishes writing STDOUT, which means some users/roles aren't being dumped. Anyone else run into this problem? What is the solution? Thanks, Rob ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] psql Segmentation fault
Tom Lane wrote: Robert Landrum [EMAIL PROTECTED] writes: Since we converted to PG8, we've been experiencing segfaults when the psql client exits. Hmm. We have heard that reported on OS X because of a bug in Apple's version of libedit, but not on any flavor of Linux. Your tests seem to eliminate libreadline as the cause anyway. Might be a corrupt copy of libpq --- have you tried reinstalling that? Actually, our build host contained some old readline libs, which ended up being statically linked into one of the libs. The fix was to remove all the dependencies from our build host, reinstall those dependencies, and then build postgres anew. Thanks for your suggestions... Rob ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[GENERAL] Indexing Hostnames with tsearch2 and fti.c
We're currently using the old fti.c code for searching our database. It's indexing a mixed bag of hostnames, employee names, ticket subjects, and the like. We hacked it to make it work correctly for hostnames, ignoring whitespace and periods as word boundaries. Since were moving to 8.2, we noticed fti.c was no longer included in the distro. Our hacked version still compiles, bit it appears that everyone is switching to tsearch2, and now is a good time to update. Has anyone used tsearch2 for indexing/searching hostnames? What's involved? I believe it's possible with a custom dictionary, but don't have any experience with writing them. We currently index about 50 records. Will tsearch2 have any trouble sifting through that many records? Thanks, Rob ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[GENERAL] Stored Proc Problem
I'm writing a stored procedure that will execute as a trigger. Arguments being passed to the procedure are field names. My goal is to convert those field names into the field values. However, I've not been successful. I thought that the following should have worked. EXECUTE ''field_val := NEW.''||tg_argv[1]||'';''; Nor does EXECUTE ''SELECT INTO field_val NEW.''||tg_argv[1]||'';''; I've tried using open for execute too... No luck. Is this possible in pure SQL? Rob ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[GENERAL] GiST Support in 8.1
We're migrating from a 7.4 (Linux AS2.1) system to an 8.1.5 (Linux RHEL4 X64) system. In 7.4, we used tsearch (txtidx fields) on some tables. When we attempt to load the indexes for those fields in 8.1.5, we get a strange SEGV. \d historyticket [cut] short_summary_idx | txtidx | [cut] X= CREATE INDEX historyticket_idx_12 ON historyticket USING gist (short_summary_idx); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. ! From the server log: LOG: statement: CREATE INDEX historyticket_idx_12 ON historyticket USING gist (short_summary_idx); LOG: server process (PID 813) was terminated by signal 11 LOG: terminating any other active server processes LOG: connection received: host=[local] FATAL: the database system is in recovery mode LOG: all server processes terminated; reinitializing LOG: database system was interrupted at 2007-07-24 14:20:17 EDT LOG: checkpoint record is at 6/65BCD58 LOG: redo record is at 6/65BCD58; undo record is at 0/0; shutdown TRUE LOG: next transaction ID: 46991; next OID: 161629 LOG: next MultiXactId: 1; next MultiXactOffset: 0 LOG: database system was not properly shut down; automatic recovery in progress LOG: redo starts at 6/65BCDA8 LOG: unexpected pageaddr 5/FD5D4000 in log file 6, segment 6, offset 6111232 LOG: redo done at 6/65D3F40 LOG: database system is ready LOG: transaction ID wrap limit is 1073785792, limited by database XX Anyone else run into this problem? Unfortunately, I didn't set up tsearch on the 7.4 system, so perhaps I've missed something obvious. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] GiST Support in 8.1
Tom Lane wrote: 8.1.5 isn't exactly the latest, but I don't see any relevant-looking gist or tsearch2 fixes in the CVS history since then, so this may still be a live bug. As it turns out, tsearch is considered obsolete, and I should be using tsearch2. Talk about being behind the times... :) I've started the migration to tsearch2, and expect that it will solve my problems. And we're building new RPMs for 8.2.x tree now. Thanks, Rob ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
