Re: Reorganize collation lookup time and place - Mailing list pgsql-hackers
From | Andreas Karlsson |
---|---|
Subject | Re: Reorganize collation lookup time and place |
Date | |
Msg-id | 14492493-fc1b-e95c-e07b-99ff67b60c86@proxel.se Whole thread Raw |
In response to | Reorganize collation lookup time and place (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Responses |
Re: Reorganize collation lookup time and place
|
List | pgsql-hackers |
On 12/10/18 4:12 PM, Peter Eisentraut wrote: > Attached is a patch that reorganizes how and where collations are looked up. > > Until now, a fmgr C function that makes use of collation information > (for example varstr_cmp(), str_toupper()) gets passed the collation OID, > looks up the collation with pg_newlocale_from_collation(), and then does > something with it. > > With this change, the lookup is moved earlier, typically during executor > initialization. The fmgr functions receive the locale pointer that is > the result of that lookup. Sounds like a great plan. I too feel that having the look ups there makes more logical sense. But when taking a look at your patch I got a segfault when running initdb. See the stack trace below. My compiler is "gcc (Debian 8.2.0-9) 8.2.0" and the locale when running initdb is glibc's "en_US.utf8". #0 __GI___strcoll_l (s1=0x55d64555d998 "({CONST :consttype 1009 :consttypmod -1 :constcollid 100 :constlen -1 :constbyval false :constisnull false :location 160 :constvalue 16 [ 64 0 0 0 0 0 0 0 0 0 0 0 25 0 0 0 ]})", s2=0x55d64555ddb0 "({CONST :consttype 1009 :consttypmod -1 :constcollid 100 :constlen -1 :constbyval false :constisnull false :location 161 :constvalue 16 [ 64 0 0 0 0 0 0 0 0 0 0 0 25 0 0 0 ]})", l=0x0) at strcoll_l.c:259 #1 0x000055d644c4d607 in varstrfastcmp_locale (x=94378777346072, y=94378777347120, ssup=0x7ffea6a64990) at varlena.c:2185 #2 0x000055d644958dad in ApplySortComparator (ssup=0x7ffea6a64990, isNull2=false, datum2=<optimized out>, isNull1=false, datum1=<optimized out>) at ../../../src/include/utils/sortsupport.h:224 #3 compare_scalars (a=<optimized out>, b=<optimized out>, arg=0x7ffea6a64980) at analyze.c:2784 #4 0x000055d644cba494 in qsort_arg (a=a@entry=0x55d6456ee5f0, n=n@entry=14, es=es@entry=16, cmp=cmp@entry=0x55d644958d82 <compare_scalars>, arg=arg@entry=0x7ffea6a64980) at qsort_arg.c:140 #5 0x000055d64495b833 in compute_scalar_stats (stats=0x55d6456c6c88, fetchfunc=0x55d6449597f1 <std_fetch_func>, samplerows=2904, totalrows=2904) at analyze.c:2360 #6 0x000055d64495cca3 in do_analyze_rel (onerel=onerel@entry=0x7f3424bdbd50, options=options@entry=2, params=params@entry=0x7ffea6a64d90, va_cols=va_cols@entry=0x0, acquirefunc=0x55d64495901b <acquire_sample_rows>, relpages=77, inh=false, in_outer_xact=false, elevel=13) at analyze.c:527 #7 0x000055d64495d2ec in analyze_rel (relid=<optimized out>, relation=0x0, options=options@entry=2, params=params@entry=0x7ffea6a64d90, va_cols=0x0, in_outer_xact=<optimized out>, bstrategy=0x55d6455413a8) at analyze.c:258 #8 0x000055d6449d61b1 in vacuum (options=2, relations=0x55d645541520, params=params@entry=0x7ffea6a64d90, bstrategy=<optimized out>, bstrategy@entry=0x0, isTopLevel=<optimized out>) at vacuum.c:357 #9 0x000055d6449d644c in ExecVacuum (vacstmt=vacstmt@entry=0x55d645442e50, isTopLevel=isTopLevel@entry=true) at vacuum.c:141 #10 0x000055d644b5ec9d in standard_ProcessUtility (pstmt=0x55d6454431a0, queryString=0x55d645442468 "ANALYZE;\n", context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x55d644f50b00 <debugtupDR>, completionTag=0x7ffea6a650d0 "") at utility.c:670 #11 0x000055d644b5f1cc in ProcessUtility (pstmt=pstmt@entry=0x55d6454431a0, queryString=<optimized out>, context=<optimized out>, params=<optimized out>, queryEnv=<optimized out>, dest=dest@entry=0x55d644f50b00 <debugtupDR>, completionTag=0x7ffea6a650d0 "") at utility.c:360 #12 0x000055d644b5b582 in PortalRunUtility (portal=portal@entry=0x55d645434428, pstmt=pstmt@entry=0x55d6454431a0, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false, dest=dest@entry=0x55d644f50b00 <debugtupDR>, completionTag=completionTag@entry=0x7ffea6a650d0 "") at pquery.c:1175 #13 0x000055d644b5c1fd in PortalRunMulti (portal=portal@entry=0x55d645434428, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false, dest=dest@entry=0x55d644f50b00 <debugtupDR>, altdest=altdest@entry=0x55d644f50b00 <debugtupDR>, completionTag=completionTag@entry=0x7ffea6a650d0 "") at pquery.c:1321 #14 0x000055d644b5cfbb in PortalRun (portal=portal@entry=0x55d645434428, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true, dest=dest@entry=0x55d644f50b00 <debugtupDR>, altdest=altdest@entry=0x55d644f50b00 <debugtupDR>, completionTag=0x7ffea6a650d0 "") at pquery.c:796 #15 0x000055d644b591b8 in exec_simple_query (query_string=query_string@entry=0x55d645442468 "ANALYZE;\n") at postgres.c:1215 #16 0x000055d644b5b0dd in PostgresMain (argc=<optimized out>, argv=<optimized out>, dbname=<optimized out>, username=<optimized out>) at postgres.c:4256 #17 0x000055d644a3abf9 in main (argc=10, argv=0x55d6453c3490) at main.c:224
pgsql-hackers by date: