SEO

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]

XXXXX=> 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 "XXXXXX"


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

Robert Landrum <rlandrum@aol.net> writes:
> 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.

Can you provide a stack trace from the crash? Or a self-contained test
case for someone else to debug?

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.

regards, tom lane

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

http://www.postgresql.org/docs/faq

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