On 10/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> > During restoration to 8.3 I've catched segfaults -- during INSERTs
> > into tables with "tsearch2"."tsvector" columns.
>
> Segfaults? That shouldn't happen. Please show a test case.
Test case: use old tsearch2.so to register all tsearch2 functions to
"tsearch2" schema (old fashioned way). Then try:
nikolay=# select '111'::tsearch2.tsvector;
ERROR: invalid memory alloc request size 1878491112
nikolay=# select '111'::tsearch2.tsvector;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x082c2d91 in gettoken_tsvector (state=0xbfae77cc, strval=0x100,
lenval=0x0, pos_ptr=0xbfae7a1c, poslen=0x0, endptr=0x0) at
tsvector_parser.c:209
209 RETURN_TOKEN;
(gdb) bt
#0 0x082c2d91 in gettoken_tsvector (state=0xbfae77cc, strval=0x100,
lenval=0x0, pos_ptr=0xbfae7a1c, poslen=0x0, endptr=0x0) at
tsvector_parser.c:209
#1 0xa730d85f in tsvector_in () from /test/lib/postgresql/tsearch2.so
#2 0x082dda5f in InputFunctionCall (flinfo=0x0, str=0x8479c00 "111",
typioparam=61357, typmod=-1) at fmgr.c:1835
#3 0x082dfe26 in OidInputFunctionCall (functionId=61358,
str=0x8479c00 "111", typioparam=61357, typmod=-1) at fmgr.c:1939
#4 0x081317a7 in stringTypeDatum (tp=0xa732eef8, string=0x8479c00
"111", atttypmod=-1) at parse_type.c:462
#5 0x081343bd in coerce_type (pstate=0x8479bb4, node=0x8479ec0,
inputTypeId=705, targetTypeId=61357, targetTypeMod=-1,
ccontext=COERCION_EXPLICIT,
cformat=COERCE_EXPLICIT_CAST) at parse_coerce.c:210
#6 0x08134b8c in coerce_to_target_type (pstate=0x8479bb4,
expr=0x8479ec0, exprtype=705, targettype=61357, targettypmod=-1,
ccontext=COERCION_EXPLICIT,
cformat=COERCE_EXPLICIT_CAST) at parse_coerce.c:81
#7 0x081279d3 in typecast_expression (pstate=0x8479bb4,
expr=0x8479ec0, typename=0x8479cd4) at parse_expr.c:2221
#8 0x0812872b in transformExpr (pstate=0x8479bb4, expr=0x8479d00) at
parse_expr.c:150
#9 0x081369fc in transformTargetEntry (pstate=0x8479bb4,
node=0x8479d00, expr=0x0, colname=0x0, resjunk=0 '\0') at
parse_target.c:74
#10 0x08136ed4 in transformTargetList (pstate=0x8479bb4,
targetlist=0x8479d5c) at parse_target.c:146
#11 0x0810f188 in transformStmt (pstate=0x8479bb4,
parseTree=0x8479d78) at analyze.c:695
#12 0x0811103f in parse_analyze (parseTree=0x8479d78,
sourceText=0x847939c "select '111'::tsearch2.tsvector;",
paramTypes=0x0, numParams=0) at analyze.c:96
#13 0x0822e00e in pg_analyze_and_rewrite (parsetree=0x8479d78,
query_string=0x847939c "select '111'::tsearch2.tsvector;",
paramTypes=0x0, numParams=0)
at postgres.c:596
#14 0x0822e1b9 in exec_simple_query (query_string=0x847939c "select
'111'::tsearch2.tsvector;") at postgres.c:899
#15 0x0822fde6 in PostgresMain (argc=4, argv=<value optimized out>,
username=0x841f508 "nikolay") at postgres.c:3529
#16 0x081ff938 in ServerLoop () at postmaster.c:3181
#17 0x08200656 in PostmasterMain (argc=3, argv=0x841b878) at postmaster.c:1027
#18 0x081b34c0 in main (argc=3, argv=0xbfae7a4c) at main.c:188
I don't think that it's abnormal, because segfault was caused by old
.so. Nothing wrong, right? But what we should worry about is the fact
that some users will follow the same way I did and will have this
segfault too... Maybe we should notice that one should remove old
tsearch.so during upgrade process (the case when one runs 8.2 and 8.3
on the same machine).
--
Best regards,
Nikolay
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
