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@alternize.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-bugs@postgresql.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
>