Horton

Re: invalid memory alloc request size error with commit 4b93f579

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Rushabh Lathia <rushabh.lathia@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-02-26T19:52:06Z
Lists: pgsql-hackers 
Rushabh Lathia <rushabh.lathia@gmail.com> writes:
> In ExecBRUpdateTriggers(), we need to add a check that if trigtuple is same
> as newtuple, then we don't require to free the trigtuple.

Hm.  Seems like this is a very old bug: it's always been legal for a
trigger to return the "old" tuple if it felt like it, even if plpgsql
didn't happen to exercise that case.

Because of that angle, I'm not really happy with using plpgsql as
part of the test case.  The bug ought to be repaired in the back
branches too, but this test will prove little in the back branches.
Moreover, if somebody were to rejigger plpgsql again, the test might
stop proving anything at all.

I wonder whether it is worth creating a C trigger function
(probably in regress.c) specifically to exercise this situation.
If not, I'm inclined not to bother with adding a test case.

			regards, tom lane

Commits

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

  2. Improve regression test coverage of regress.c.

  3. Remove unused functions in regress.c.

  4. Make plpgsql use its DTYPE_REC code paths for composite-type variables.

  5. This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support.