Postgres Pro
Downloads
Home   >   mailing lists

Thread: BUG #1158: tsearch2 trigger crashes machine

BUG #1158: tsearch2 trigger crashes machine

From
"PostgreSQL Bugs List"
Date:
The following bug has been logged online:

Bug reference:      1158
Logged by:          Werner Bohl

Email address:      wbohl@deepdata.com

PostgreSQL version: 7.4

Operating system:   RH Linux 9, kernel 2.4.20-31

Description:        tsearch2 trigger crashes machine

Details:

Using tsearch2's trigger to index a fairly short (varchar(200)) field with
names of business crashes Linux.

Table used has 39 fields, one of which is the business name. Bulk-inserting
thousands of records (>50,000) crashes Linux. Error appeared consistently
on 4 import trials, first time @ 130,000 records, second @ 160,000 records,
third @ 64,000 records.

Table has a pkey and also is indexed 'using gist(FIELD_NAME)' where
FIELD_NAME is the tsvector field.

Table resides alone in his own db & schema (public).

Linux is severly affected and the machine needs a RESET to be able to boot.
(shutdown nor init 6 work!!)

Re: BUG #1158: tsearch2 trigger crashes machine

From
Tom Lane
Date:
"PostgreSQL Bugs List" <pgsql-bugs@postgresql.org> writes:
> Linux is severly affected and the machine needs a RESET to be able to boot.
> (shutdown nor init 6 work!!)

Sure you're not looking at hardware problems?  PG should certainly not
be able to crash a properly functioning kernel (since PG isn't a
privileged process) and I haven't heard many complaints against later
2.4 series kernels either.  My money is on flaky hardware...

            regards, tom lane

Re: BUG #1158: tsearch2 trigger crashes machine

From
Werner Bohl
Date:
On Sun, 2004-05-30 at 22:45, Tom Lane wrote:
> "PostgreSQL Bugs List" <pgsql-bugs@postgresql.org> writes:
> > Linux is severly affected and the machine needs a RESET to be able to boot.
> > (shutdown nor init 6 work!!)
>
> Sure you're not looking at hardware problems?  PG should certainly not
> be able to crash a properly functioning kernel (since PG isn't a
> privileged process) and I haven't heard many complaints against later
> 2.4 series kernels either.  My money is on flaky hardware...
>

Running the bulk insert process without the trigger does work well. We
did an update to the tsvector afterwards and it also worked without a
hitch. Therefore I suspect of the trigger.

TIA,