Re: Segmentation fault with PG-12

[Andreas Joseph Krogh <andreas@xxxxxxxxxx>]

På torsdag 10. oktober 2019 kl. 07:25:26, skrev Andres Freund <andres@xxxxxxxxxxx>:

On 2019-10-09 10:16:37 -0400, Tom Lane wrote:
> Andreas Joseph Krogh <andreas@xxxxxxxxxx> writes:
> > Attached is output from "bt full". Is this helpful?
>
> Well, it shows that the failure is occurring while trying to evaluate
> a variable in a trigger's WHEN clause during
> "UPDATE origo_email_delivery SET folder_id=$1, created=$2\nWHERE entity_id IN ($3)\nRETURNING entity_id"
> And I'd bet that the root cause is something to do with Andres' tuple slot
> work.  But (at least to my eye) it's not apparent exactly what's wrong.

It looks like this could "just" be another report of #16036, which was
already fixed in:

commit d986d4e87f61c68f52c68ebc274960dc664b7b4e
Author: Andres Freund <andres@xxxxxxxxxxx>
Date:   2019-10-04 11:59:34 -0700

    Fix crash caused by EPQ happening with a before update trigger present.

 

 

 

(Tom: This mail is only viewable as text/html, to if you're reading the text/plain version it will seem "hashed")

 

Aha, that whould be 60e97d63e5d19098e11fa32431a20eea820e2ae9 in REL_12_STABLE

We'll build and run HEAD of REL_12_STABLE, and report back.

 

 

> This doesn't seem to correlate with your original report, btw,
> as that claimed the crash was during COMMIT.

That however, would be confusing, unless there's some deferred trigger
that causes another update, which then fires a before update trigger
causing the problem.

Greetings,

Andres Freund

 

We have a deferred trigger which updates origo_email_delivery:

 

CREATE OR REPLACE FUNCTION origo_index_email_props_tf() RETURNS TRIGGER AS
$$
declare
    v_prop origo_email_message_property;
BEGIN
    v_prop := NEW;
    UPDATE origo_email_delivery
    SET is_seen      = v_prop.is_seen,
        followup_id  = v_prop.followup_id,
        is_replied   = v_prop.is_replied,
        is_forwarded = v_prop.is_forwarded,
        is_draft     = v_prop.is_draft,
        is_done      = v_prop.is_done,
        is_flagged   = v_prop.is_flagged,
        modseq       = greatest(modseq, v_prop.modseq)
    WHERE message_id = v_prop.message_id
      AND owner_id = v_prop.owner_id;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE CONSTRAINT TRIGGER origo_index_email_props_t
    AFTER INSERT OR UPDATE
    ON origo_email_message_property DEFERRABLE INITIALLY DEFERRED
    FOR EACH ROW
EXECUTE PROCEDURE origo_index_email_props_tf();

 

.. and then trigger the following UPDATE-trigger:

 

CREATE TRIGGER origo_email_delivery_update_t
    BEFORE UPDATE
    ON origo_email_delivery
    FOR EACH ROW
    WHEN (OLD.folder_id <> NEW.folder_id OR NEW.is_deleted <> OLD.is_deleted)
EXECUTE PROCEDURE origo_email_delivery_update_tf();

 

Maybe that will trigger the bug.

 

Thanks.

 

--

Andreas Joseph Krogh

CTO / Partner - Visena AS

Mobile: +47 909 56 963

andreas@xxxxxxxxxx

www.visena.com