Horton

Re: Segmentation fault during update inside ExecBRUpdateTriggers

Thomas Munro <thomas.munro@gmail.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Piotr Gabriel Kosinski <pg.kosinski@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-08-15T23:35:39Z
Lists: pgsql-bugs

Attachments

On Fri, Aug 16, 2019 at 11:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
> > [ thinks some more... ]  Actually, I'm beginning to recall that
> > we made changes here because v11 plpgsql is capable of actually
> > returning "trigtuple" where before it would always have made a copy.
> > If that's accurate, then very likely the bug exists further back
> > but requires some other PL than plpgsql to manifest.
>
> As I suspected ... the attached test case crashes 9.4 through 11.
> We already had some problems in this area, which is why a suitable
> trigger is already at hand in regress.c.

Ah, I see.  I had written a test patch that uses plpgsql (attached for
posterity) but yours is better because it crashes more releases.  I
will now get out of your way :-)

-- 
Thomas Munro
https://enterprisedb.com

Commits

  1. Prevent possible double-free when update trigger returns old tuple.

  2. Prevent dangling-pointer access when update trigger returns old tuple.