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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: invalid memory alloc request size error with commit 4b93f579
Date: 2018-02-26 19:52:06
Message-ID: 5931.1519674726@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-02-26 19:55:45 Re: Precision loss casting float to numeric
Previous Message Chapman Flack 2018-02-26 19:40:06 Re: Precision loss casting float to numeric