Re: [HACKERS] delta relations in AFTER triggers - Mailing list pgsql-hackers

From David Steele
Subject Re: [HACKERS] delta relations in AFTER triggers
Date
Msg-id ee4038f8-25be-1667-e0f0-05ae09ca7e05@pgmasters.net
Whole thread Raw
In response to Re: [HACKERS] delta relations in AFTER triggers  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] delta relations in AFTER triggers  (Kevin Grittner <kgrittn@gmail.com>)
List pgsql-hackers
Hi Kevin,

On 2/20/17 10:43 PM, Thomas Munro wrote:
> On Tue, Feb 21, 2017 at 7:14 AM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>> On Fri, Jan 20, 2017 at 2:49 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
>>> Attached is v9 which fixes bitrot from v8.  No other changes.
>>>
>>> Still needs review.
> 
> Based on a suggestion from Robert off-list I tried inserting into a
> delta relation from a trigger function and discovered that it
> segfaults:
> 
>   * frame #0: 0x00000001057705a6
> postgres`addRangeTableEntryForRelation(pstate=0x00007fa58186a4d0,
> rel=0x0000000000000000, alias=0x0000000000000000, inh='\0',
> inFromCl='\0') + 70 at parse_relation.c:1280 [opt]
>     frame #1: 0x000000010575bbda
> postgres`setTargetTable(pstate=0x00007fa58186a4d0,
> relation=0x00007fa58186a098, inh=<unavailable>, alsoSource='\0',
> requiredPerms=1) + 90 at parse_clause.c:199 [opt]
>     frame #2: 0x0000000105738530 postgres`transformStmt [inlined]
> transformInsertStmt(pstate=<unavailable>) + 69 at analyze.c:540 [opt]
>     frame #3: 0x00000001057384eb
> postgres`transformStmt(pstate=<unavailable>, parseTree=<unavailable>)
> + 2411 at analyze.c:279 [opt]
>     frame #4: 0x0000000105737a42
> postgres`transformTopLevelStmt(pstate=<unavailable>,
> parseTree=0x00007fa58186a438) + 18 at analyze.c:192 [opt]
>     frame #5: 0x00000001059408d0
> postgres`pg_analyze_and_rewrite_params(parsetree=0x00007fa58186a438,
> query_string="insert into d values (1000000, 1000000, 'x')",
> parserSetup=(plpgsql.so`plpgsql_parser_setup at pl_comp.c:1017),
> parserSetupArg=0x00007fa58185c2a0, queryEnv=0x00007fa581857798) + 128
> at postgres.c:706 [opt]

Do you know when you will have a new patch ready?

This looks like an interesting and important feature but I think it's
going to have to come together quickly if it's going to make it into v10.

Thanks,
-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: [HACKERS] [PATCH] kNN for btree
Next
From: David Steele
Date:
Subject: Re: [HACKERS] Proposal for changes to recovery.conf API