Re: 8.2beta1 (w32): server process crash (tsvector) - Mailing list pgsql-bugs
From | |
---|---|
Subject | Re: 8.2beta1 (w32): server process crash (tsvector) |
Date | |
Msg-id | 0a5501c6f229$7da1bb50$6501a8c0@iwing Whole thread Raw |
In response to | 8.2beta1 (w32): server process crash (tsvector) (<me@alternize.com>) |
Responses |
Re: 8.2beta1 (w32): server process crash (tsvector)
|
List | pgsql-bugs |
>> 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
pgsql-bugs by date: