Re: 8.2beta1 (w32): server process crash (tsvector)

this bug (please see below) is unfortunately still present in beta3 (win32
build). test case still crashes the child process and lets postmaster kill &
reload everything.

it is not GiST-related, i've just validated the same problem using GIN.

this breaks tsearch2 functionality on our win32 system as no
tsvector-indexing of new/existing rows is possible (crash after ~10
processed rows). searching already indexed rows works fine.

best regards,
thomas

----- Original Message -----
From: <me(at)alternize(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-bugs(at)postgresql(dot)org>
Sent: Tuesday, October 17, 2006 9:19 PM
Subject: Re: [BUGS] 8.2beta1 (w32): server process crash (tsvector)

>>> the following query will crash the server process:
>>> INSERT INTO news.news
>>> SELECT * FROM news.news2;
>>
>> This is undoubtedly data-dependent. Can you supply some sample data
>> that makes it happen?
>
> it's not only happening with INSERTS, but also updates. as thats easier to
> test, here's how i can reproduce the error:
>
> 1. create new database (encoding: UTF8) with tsearch2 on 8.2b1 win32
> (system
> locale: de_CH.1252)
> 2. insert the data from the zip file
> [http://alternize.com/pgsql/tsearch2test.zip] (be sure to also update
> pg_ts_cf /
> pg_ts_cfgmap as we have WIN1252 locale)
> 3. execute UPDATE test SET idxFTI = to_tsvector('default', "sometext"); or
> similar queries
> 4. hopefully see the process crashing as i do ;-)
>
>
> 2006-10-17 17:23:44 LOG: server process (PID 4584) exited with exit
> code -1073741819
> 2006-10-17 17:23:44 LOG: terminating any other active server processes
> 2006-10-17 17:23:44 WARNING: terminating connection because of crash of
> another server process
> 2006-10-17 17:23:44 DETAIL: The postmaster has commanded this server
> process to roll back the current transaction and exit, because another
> server process exited abnormally and possibly corrupted shared memory.
> {snipp}
> 2006-10-17 17:23:44 LOG: all server processes terminated; reinitializing
> 2006-10-17 17:23:44 LOG: database system was interrupted at 2006-10-17
> 17:23:41 W. Europe Daylight Time
> 2006-10-17 17:23:44 LOG: Windows fopen("recovery.conf","r") failed: code
> 2,
> errno 2
> 2006-10-17 17:23:44 LOG: Windows fopen("pg_xlog/00000001.history","r")
> failed: code 2, errno 2
> 2006-10-17 17:23:44 LOG: Windows fopen("backup_label","r") failed: code
> 2,
> errno 2
> 2006-10-17 17:23:44 LOG: checkpoint record is at 0/E2ECA728
> 2006-10-17 17:23:44 LOG: redo record is at 0/E2ECA728; undo record is at
> 0/0; shutdown FALSE
> 2006-10-17 17:23:44 LOG: next transaction ID: 0/514299; next OID: 6276957
> 2006-10-17 17:23:44 LOG: next MultiXactId: 1; next MultiXactOffset: 0
> 2006-10-17 17:23:44 LOG: database system was not properly shut down;
> automatic recovery in progress
> 2006-10-17 17:23:44 LOG: redo starts at 0/E2ECA778
> 2006-10-17 17:23:44 LOG: unexpected pageaddr 0/DB0CC000 in log file 0,
> segment 227, offset 835584
> 2006-10-17 17:23:44 LOG: redo done at 0/E30CBE78
> 2006-10-17 17:23:45 LOG: database system is ready
> 2006-10-17 17:23:45 LOG: Windows fopen("global/pg_fsm.cache","rb")
> failed:
> code 2, errno 2
> 2006-10-17 17:23:45 LOG: transaction ID wrap limit is 2147484172, limited
> by database "postgres"
> 2006-10-17 17:23:45 LOG: Windows fopen("global/pgstat.stat","rb") failed:
> code 2, errno 2
>
>
> i've also tried to update each record on its own in a for-loop. here the
> crash happens as well, sometimes after 10 updates, sometimes after 100
> updates, sometimes even after 1 update. but eventually every record can be
> updated. so i do not think its entierly content-related...
>
> for what its worth, here's the output of pg_controldata:
>
> pg_control version number: 822
> Catalog version number: 200609181
> Database system identifier: 4986650172201464825
> Database cluster state: in production
> pg_control last modified: 17.10.2006 17:44:29
> Current log file ID: 0
> Next log file segment: 230
> Latest checkpoint location: 0/E4E0F978
> Prior checkpoint location: 0/E46BF420
> Latest checkpoint's REDO location: 0/E4E03098
> Latest checkpoint's UNDO location: 0/0
> Latest checkpoint's TimeLineID: 1
> Latest checkpoint's NextXID: 0/531333
> Latest checkpoint's NextOID: 6285149
> Latest checkpoint's NextMultiXactId: 1
> Latest checkpoint's NextMultiOffset: 0
> Time of latest checkpoint: 17.10.2006 17:43:45
> Minimum recovery ending location: 0/0
> Maximum data alignment: 8
> Database block size: 8192
> Blocks per segment of large relation: 131072
> WAL block size: 8192
> Bytes per WAL segment: 16777216
> Maximum length of identifiers: 64
> Maximum columns in an index: 32
> Date/time type storage: floating-point numbers
> Maximum length of locale name: 128
> LC_COLLATE: German_Switzerland.1252
> LC_CTYPE: German_Switzerland.1252
>
> let me know if more information / data is needed.
>
> on a sidenote: are those fopen() errors debug-code-leftovers or something
> one should worry about? i can't find those files on the file system.
>
> - thomas
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>