Home > mailing lists

Re: Segmentation fault with PG-12 - Mailing list pgsql-general

From	Andreas Joseph Krogh
Subject	Re: Segmentation fault with PG-12
Date	October 10, 2019 10:05:06
Msg-id	VisenaEmail.15.db251c0f6645bb8a.16db46dfe94@tc7-visena Whole thread Raw
In response to	Re: Segmentation fault with PG-12 (Andres Freund <andres@anarazel.de>)
Responses	Re: Segmentation fault with PG-12
List	pgsql-general

Tree view

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

On 2019-10-09 10:16:37 -0400, Tom Lane wrote:
> Andreas Joseph Krogh <andreas@visena.com> 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@anarazel.de>
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();