Re: pgsql: Use slots in trigger infrastructure, except for theactual invoc - Mailing list pgsql-committers

From Andres Freund
Subject Re: pgsql: Use slots in trigger infrastructure, except for theactual invoc
Date
Msg-id 20190228204138.ao7odx4qvevu63fq@alap3.anarazel.de
Whole thread Raw
In response to Re: pgsql: Use slots in trigger infrastructure, except for theactual invoc  (Andres Freund <andres@anarazel.de>)
Responses Re: pgsql: Use slots in trigger infrastructure, except for the actualinvoc  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-committers
Hi,

On 2019-02-27 10:16:21 -0800, Andres Freund wrote:
> On 2019-02-27 12:59:16 -0500, Andrew Dunstan wrote:
> > Backtraces should be enabled in the animal - I will investigate why
> > we're not getting them here. Meanwhile, here's one for this problem:
> 
> Thanks, that helps!  My first theories as to what's going on fell flat,
> unfortunately. I guess I'll have to figure out how to run that locally
> :(.

The issue was just that we didn't allow materializing virtual tuples
stored in a buffer tuple table slot. Locally allowing that fixed the
problem for me, I assume that'll also fix the crake. It was already on a
list of patches for pluggable storage...

Btw, shouldn't redisExecForeignDelete return NULL when there's no row
matched for the deletion? That's possible, I'd assume, if there's a
concurrent deletion.

Greetings,

Andres Freund


pgsql-committers by date:

Previous
From: Andres Freund
Date:
Subject: pgsql: Allow buffer tuple table slots to materialize afterExecStoreVir
Next
From: Joe Conway
Date:
Subject: pgsql: Make get_controlfile not leak file descriptors