Re: Reorganize collation lookup time and place

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reorganize collation lookup time and place
Date: 2018-12-12 14:58:07
Message-ID: 14492493-fc1b-e95c-e07b-99ff67b60c86@proxel.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)entry=0x55d6456ee5f0,
n=n(at)entry=14, es=es(at)entry=16, cmp=cmp(at)entry=0x55d644958d82
<compare_scalars>, arg=arg(at)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(at)entry=0x7f3424bdbd50, options=options(at)entry=2,
params=params(at)entry=0x7ffea6a64d90, va_cols=va_cols(at)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(at)entry=2,
params=params(at)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(at)entry=0x7ffea6a64d90, bstrategy=<optimized out>,
bstrategy(at)entry=0x0, isTopLevel=<optimized out>) at vacuum.c:357
#9 0x000055d6449d644c in ExecVacuum
(vacstmt=vacstmt(at)entry=0x55d645442e50, isTopLevel=isTopLevel(at)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(at)entry=0x55d6454431a0, queryString=<optimized out>,
context=<optimized out>, params=<optimized out>, queryEnv=<optimized
out>, dest=dest(at)entry=0x55d644f50b00 <debugtupDR>,
completionTag=0x7ffea6a650d0 "") at utility.c:360
#12 0x000055d644b5b582 in PortalRunUtility
(portal=portal(at)entry=0x55d645434428, pstmt=pstmt(at)entry=0x55d6454431a0,
isTopLevel=isTopLevel(at)entry=true,
setHoldSnapshot=setHoldSnapshot(at)entry=false,
dest=dest(at)entry=0x55d644f50b00 <debugtupDR>,
completionTag=completionTag(at)entry=0x7ffea6a650d0 "") at pquery.c:1175
#13 0x000055d644b5c1fd in PortalRunMulti
(portal=portal(at)entry=0x55d645434428, isTopLevel=isTopLevel(at)entry=true,
setHoldSnapshot=setHoldSnapshot(at)entry=false,
dest=dest(at)entry=0x55d644f50b00 <debugtupDR>,
altdest=altdest(at)entry=0x55d644f50b00 <debugtupDR>,
completionTag=completionTag(at)entry=0x7ffea6a650d0 "") at pquery.c:1321
#14 0x000055d644b5cfbb in PortalRun (portal=portal(at)entry=0x55d645434428,
count=count(at)entry=9223372036854775807, isTopLevel=isTopLevel(at)entry=true,
run_once=run_once(at)entry=true, dest=dest(at)entry=0x55d644f50b00
<debugtupDR>, altdest=altdest(at)entry=0x55d644f50b00 <debugtupDR>,
completionTag=0x7ffea6a650d0 "") at pquery.c:796
#15 0x000055d644b591b8 in exec_simple_query
(query_string=query_string(at)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergei Kornilov 2018-12-12 15:55:04 Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name
Previous Message Daniel Verite 2018-12-12 14:57:50 Re: [HACKERS] Can ICU be used for a database's default sort order?