Re: 8.2beta1 (w32): server process crash (tsvector) - Mailing list pgsql-bugs
From | Thomas H. |
---|---|
Subject | Re: 8.2beta1 (w32): server process crash (tsvector) |
Date | |
Msg-id | 037601c6f862$77029820$6501a8c0@iwing Whole thread Raw |
In response to | 8.2beta1 (w32): server process crash (tsvector) (<me@alternize.com>) |
List | pgsql-bugs |
just a small update: this problem is also present in beta 2. not a big problem for the moment, as we currently have disabled fulltext search capabilities on the website. regards, thomas ----- Original Message ----- From: <me@alternize.com> To: "Tom Lane" <tgl@sss.pgh.pa.us> Cc: <pgsql-bugs@postgresql.org> Sent: Tuesday, October 17, 2006 10: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 >
pgsql-bugs by date: