Re: [PATCH] Pattern based listeners for asynchronous messaging (LISTEN/NOTIFY)

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Markus Sintonen <markus(dot)sintonen(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Pattern based listeners for asynchronous messaging (LISTEN/NOTIFY)
Date: 2017-08-18 23:36:32
Message-ID: CAEepm=1jJoDrvQMfQUetbeOMFHogDtbCjAWEt5vV2y+8F8+2qQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 1, 2017 at 8:13 AM, Markus Sintonen
<markus(dot)sintonen(at)gmail(dot)com> wrote:
> This patch adds an ability to use patterns in LISTEN commands. Patch uses
> 'SIMILAR TO' patterns for matching NOTIFY channel names
> (https://www.postgresql.org/docs/9.0/static/functions-matching.html#FUNCTIONS-SIMILARTO-REGEXP).
>
> This patch is related to old discussion in
> https://www.postgresql.org/message-id/52693FC5.7070507@gmail.com. This
> discussion contains the reasoning behind the pattern based matching of the
> channel names.

Nice idea.

The "async" regression test consistently crashes on my FreeBSD box
when built with -O2. It doesn't crash on another system I tried, and
I think that's just luck, because this:

+ /* convert to regex pattern */
+ datum = DirectFunctionCall1(similar_escape,
CStringGetTextDatum(pattern));

... is calling a function that takes two arguments, but passing only
one. The second argument is random junk, so similar_escape bombs when
it does this:

esc_text = PG_GETARG_TEXT_PP(1);

(lldb) bt
* thread #1, name = 'postgres', stop reason = signal SIGSEGV
* frame #0: postgres`pg_detoast_datum_packed(datum=0x0000000000000000)
at fmgr.c:1865
frame #1: postgres`similar_escape(fcinfo=0x00007fffffffd080) at regexp.c:686
frame #2: postgres`DirectFunctionCall1Coll(func=(postgres`similar_escape
at regexp.c:659), collation=<unavailable>, arg1=<unavailable>) at
fmgr.c:717
frame #3: postgres`queue_listen(action=LISTEN_LISTEN,
pattern="notify_%", isSimilarToPattern=<unavailable>) at async.c:671
frame #4: postgres`standard_ProcessUtility(pstmt=0x0000000801824df0,
queryString="LISTEN SIMILAR TO 'notify_%';",
context=PROCESS_UTILITY_TOPLEVEL, params=0x0000000000000000,
queryEnv=0x0000000000000000, dest=0x0000000801824ee8,
completionTag=<unavailable>) at utility.c:633
frame #5: postgres`PortalRunUtility(portal=0x0000000801960040,
pstmt=0x0000000801824df0, isTopLevel='\x01',
setHoldSnapshot=<unavailable>, dest=<unavailable>, completionTag="")
at pquery.c:1178
frame #6: postgres`PortalRunMulti(portal=0x0000000801960040,
isTopLevel='\x01', setHoldSnapshot='\0', dest=0x0000000801824ee8,
altdest=0x0000000801824ee8, completionTag="") at pquery.c:0
frame #7: postgres`PortalRun(portal=0x0000000801960040,
count=<unavailable>, isTopLevel='\x01', run_once=<unavailable>,
dest=<unavailable>, altdest=<unavailable>,
completionTag=<unavailable>) at pquery.c:799
frame #8: postgres`exec_simple_query(query_string="LISTEN SIMILAR
TO 'notify_%';") at postgres.c:1099
frame #9: postgres`PostgresMain(argc=<unavailable>,
argv=<unavailable>, dbname=<unavailable>, username=<unavailable>) at
postgres.c:0
frame #10: postgres`PostmasterMain [inlined] BackendRun at postmaster.c:4357
frame #11: postgres`PostmasterMain [inlined] BackendStartup at
postmaster.c:4029
frame #12: postgres`PostmasterMain at postmaster.c:1753
frame #13: postgres`PostmasterMain(argc=<unavailable>,
argv=0x00000008018d11c0) at postmaster.c:1361
frame #14: postgres`main(argc=<unavailable>, argv=<unavailable>)
at main.c:228
frame #15: 0x00000000004823af postgres`_start + 383

--
Thomas Munro
http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-08-19 02:47:49 Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values
Previous Message David Steele 2017-08-18 22:46:12 Re: Update low-level backup documentation to match actual behavior