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: <[EMAIL PROTECTED]>
To: "Tom Lane" <[EMAIL PROTECTED]>
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




---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to