Обсуждение: Coredump with text search dictionary

When attempting use text search, here is a core dump
(reported from my friend, Song Jinzhou).

CREATE TEXT SEARCH TEMPLATE public.my_ts_template (
  init = varchar_support,
  lexize = dispell_lexize
);

CREATE TEXT SEARCH DICTIONARY public.my_ts_dict (
  template = public.my_ts_template
);

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.
The connection to the server was lost. Attempting reset: Failed.

Here is backtrace:

#0  0x00005605671bce72 in varchar_support (fcinfo=0x7ffd0c87a070)
    at /home/japin/Codes/postgresql/build/../src/backend/utils/adt/varchar.c:565
#1  0x0000560567205842 in FunctionCall1Coll (flinfo=0x7ffd0c87a0d0, collation=0, arg1=0)
    at /home/japin/Codes/postgresql/build/../src/backend/utils/fmgr/fmgr.c:1124
#2  0x000056056720675d in OidFunctionCall1Coll (functionId=3097, collation=0, arg1=0)
    at /home/japin/Codes/postgresql/build/../src/backend/utils/fmgr/fmgr.c:1402
#3  0x0000560566d650ad in verify_dictoptions (tmplId=24576, dictoptions=0x0)
    at /home/japin/Codes/postgresql/build/../src/backend/commands/tsearchcmds.c:381
#4  0x0000560566d652d1 in DefineTSDictionary (names=0x5605678ad4d8, parameters=0x5605678ad720)
    at /home/japin/Codes/postgresql/build/../src/backend/commands/tsearchcmds.c:442
#5  0x0000560567042a96 in ProcessUtilitySlow (pstate=0x5605678cd940, pstmt=0x5605678adae8,
    queryString=0x5605678aca10 "CREATE TEXT SEARCH DICTIONARY public.my_ts_dict (\n  template =
public.my_ts_template\n);",context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x5605678adbd8,
qc=0x7ffd0c87aa40)
    at /home/japin/Codes/postgresql/build/../src/backend/tcop/utility.c:1430
#6  0x0000560567041e84 in standard_ProcessUtility (pstmt=0x5605678adae8,
    queryString=0x5605678aca10 "CREATE TEXT SEARCH DICTIONARY public.my_ts_dict (\n  template =
public.my_ts_template\n);",readOnlyTree=false, context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0,
dest=0x5605678adbd8,
    qc=0x7ffd0c87aa40) at /home/japin/Codes/postgresql/build/../src/backend/tcop/utility.c:1074
#7  0x0000560567040dfe in ProcessUtility (pstmt=0x5605678adae8,
    queryString=0x5605678aca10 "CREATE TEXT SEARCH DICTIONARY public.my_ts_dict (\n  template =
public.my_ts_template\n);",readOnlyTree=false, context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0,
dest=0x5605678adbd8,
    qc=0x7ffd0c87aa40) at /home/japin/Codes/postgresql/build/../src/backend/tcop/utility.c:530
#8  0x000056056703f905 in PortalRunUtility (portal=0x56056791eed0, pstmt=0x5605678adae8, isTopLevel=true,
    setHoldSnapshot=false, dest=0x5605678adbd8, qc=0x7ffd0c87aa40)
    at /home/japin/Codes/postgresql/build/../src/backend/tcop/pquery.c:1158
#9  0x000056056703fb77 in PortalRunMulti (portal=0x56056791eed0, isTopLevel=true, setHoldSnapshot=false,
    dest=0x5605678adbd8, altdest=0x5605678adbd8, qc=0x7ffd0c87aa40)
    at /home/japin/Codes/postgresql/build/../src/backend/tcop/pquery.c:1315
#10 0x000056056703eff5 in PortalRun (portal=0x56056791eed0, count=9223372036854775807, isTopLevel=true,
    run_once=true, dest=0x5605678adbd8, altdest=0x5605678adbd8, qc=0x7ffd0c87aa40)
    at /home/japin/Codes/postgresql/build/../src/backend/tcop/pquery.c:791
#11 0x0000560567038332 in exec_simple_query (
    query_string=0x5605678aca10 "CREATE TEXT SEARCH DICTIONARY public.my_ts_dict (\n  template =
public.my_ts_template\n);")at /home/japin/Codes/postgresql/build/../src/backend/tcop/postgres.c:1243
 
#12 0x000056056703ce29 in PostgresMain (dbname=0x5605678a7168 "postgres", username=0x5605678d8d18 "japin")
    at /home/japin/Codes/postgresql/build/../src/backend/tcop/postgres.c:4505
#13 0x0000560566f64bd0 in BackendRun (port=0x5605678d4c60)
    at /home/japin/Codes/postgresql/build/../src/backend/postmaster/postmaster.c:4491
#14 0x0000560566f644be in BackendStartup (port=0x5605678d4c60)
    at /home/japin/Codes/postgresql/build/../src/backend/postmaster/postmaster.c:4219
#15 0x0000560566f60730 in ServerLoop ()
    at /home/japin/Codes/postgresql/build/../src/backend/postmaster/postmaster.c:1809
#16 0x0000560566f5fee1 in PostmasterMain (argc=1, argv=0x5605678a5120)
    at /home/japin/Codes/postgresql/build/../src/backend/postmaster/postmaster.c:1481
#17 0x0000560566e234d2 in main (argc=1, argv=0x5605678a5120)
    at /home/japin/Codes/postgresql/build/../src/backend/main/main.c:197

I found that variable dictoptions in  DefineTSDictionary() is NIL if we do not
provide any other options (expect template option), which leads the core-dump.

Here is a patch to fix this coredump.  Any thoughts?

-- 
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.

Japin Li <japinli@hotmail.com> writes:
> When attempting use text search, here is a core dump
> (reported from my friend, Song Jinzhou).

> CREATE TEXT SEARCH TEMPLATE public.my_ts_template (
>   init = varchar_support,
>   lexize = dispell_lexize
> );

> CREATE TEXT SEARCH DICTIONARY public.my_ts_dict (
>   template = public.my_ts_template
> );


There's a reason why CREATE TEXT SEARCH TEMPLATE is superuser-only:
it's on you to supply valid parameters.  varchar_support is a
completely inappropriate choice for a TS template init function.
The proposed patch doesn't add any meaningful amount of safety
(just add some options to the dictionary, and it'll still crash).
Moreover, the patch breaks init functions that would, say, want
to insist that option X be provided.

            regards, tom lane

On Tue, 09 Aug 2022 at 12:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> There's a reason why CREATE TEXT SEARCH TEMPLATE is superuser-only:
> it's on you to supply valid parameters.  varchar_support is a
> completely inappropriate choice for a TS template init function.
> The proposed patch doesn't add any meaningful amount of safety
> (just add some options to the dictionary, and it'll still crash).
> Moreover, the patch breaks init functions that would, say, want
> to insist that option X be provided.
>

Oh, my bad. I see this in documentation [1].

You must be a superuser to use CREATE TEXT SEARCH TEMPLATE. This restriction
is made because an erroneous text search template definition could confuse
or even crash the server.

However, is there any way to avoid this crash?  I'm not familiar with the TS,
I didn't see documentation that describes which function is appropriate for a
TS template init function.

[1] https://www.postgresql.org/docs/devel/sql-createtstemplate.html

-- 
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.

Japin Li <japinli@hotmail.com> writes:
> On Tue, 09 Aug 2022 at 12:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> There's a reason why CREATE TEXT SEARCH TEMPLATE is superuser-only:
>> it's on you to supply valid parameters.  varchar_support is a
>> completely inappropriate choice for a TS template init function.

> I didn't see documentation that describes which function is appropriate for a
> TS template init function.

Umm ... maybe one that claims to be a TS init function?  I'm not
sure why you're having a hard time believing that varchar_support
is not that.

            regards, tom lane

On Tue, 09 Aug 2022 at 13:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Japin Li <japinli@hotmail.com> writes:
>> On Tue, 09 Aug 2022 at 12:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> There's a reason why CREATE TEXT SEARCH TEMPLATE is superuser-only:
>>> it's on you to supply valid parameters.  varchar_support is a
>>> completely inappropriate choice for a TS template init function.
>
>> I didn't see documentation that describes which function is appropriate for a
>> TS template init function.
>
> Umm ... maybe one that claims to be a TS init function?  I'm not
> sure why you're having a hard time believing that varchar_support
> is not that.
>

I just think it's strange that the server crashes under these circumstances.


-- 
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.

Japin Li <japinli@hotmail.com> writes:
> On Tue, 09 Aug 2022 at 13:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Umm ... maybe one that claims to be a TS init function?  I'm not
>> sure why you're having a hard time believing that varchar_support
>> is not that.

> I just think it's strange that the server crashes under these circumstances.

There's no strong moral separation between this and randomly
scribbling on the contents of pg_proc.

            regards, tom lane