Re: Reorganize collation lookup time and place

Поиск
Список
Период
Сортировка
От Andreas Karlsson
Тема Re: Reorganize collation lookup time and place
Дата
Msg-id 14492493-fc1b-e95c-e07b-99ff67b60c86@proxel.se
обсуждение исходный текст
Ответ на Reorganize collation lookup time and place  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: Reorganize collation lookup time and place  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: "Daniel Verite"
Дата:
Сообщение: Re: [HACKERS] Can ICU be used for a database's default sort order?
Следующее
От: Sergei Kornilov
Дата:
Сообщение: Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name