Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane wrote:
> >> I don't think it's a bug, I think it's an intentional design tradeoff.
> >> To suppress an update in this case, the trigger would have to grovel
> >>
Hi,
It looks like you know what is happening, but I found that I have made an
error in my original assumption: (while the steps to reproduce are still
valid)
The size of the string at which the trigger does not work as expected
varies, depending on the size of the other fields in the row.
The
Robert Haas writes:
> On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane wrote:
>> I don't think it's a bug, I think it's an intentional design tradeoff.
>> To suppress an update in this case, the trigger would have to grovel
>> through the individual fields
On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane wrote:
>> Seems like in "suppress_redundant_updates_trigger" we are comparing
>> toasted tuple with the new tuple and that is the cause of the bug.
>
> I don't think it's a bug, I think it's an intentional design tradeoff.
> To
Dilip Kumar writes:
> On Mon, Jun 19, 2017 at 5:20 PM, Artus de benque
> wrote:
>> postgres=# UPDATE test_table SET field = 'hi' WHERE id = 1;
>> UPDATE 0
>> test_db=# UPDATE test_table SET field = rpad('', 2001, 'a') WHERE id = 1;
>> UPDATE 1
>>
On Mon, Jun 19, 2017 at 5:20 PM, Artus de benque
wrote:
> postgres=# UPDATE test_table SET field = 'hi' WHERE id = 1;
> UPDATE 0
> test_db=# UPDATE test_table SET field = rpad('', 2001, 'a') WHERE id = 1;
> UPDATE 1
> test_db=# UPDATE test_table SET field = rpad('', 2001,