From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Artus de benque <artusdebenque(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [BUGS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger |
Date: | 2017-06-19 15:59:05 |
Message-ID: | 644.1497887945@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Dilip Kumar <dilipbalaut(at)gmail(dot)com> writes:
> On Mon, Jun 19, 2017 at 5:20 PM, Artus de benque
> <artusdebenque(at)gmail(dot)com> 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, 'a') WHERE id = 1;
>> UPDATE 1 <--- BUG: expected 0, as we ran the same update twice
> 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 suppress an update in this case, the trigger would have to grovel
through the individual fields and detoast them before comparing.
That would add a lot of cycles, and only seldom add successes.
Possibly we should adjust the documentation so that it doesn't imply
that this trigger guarantees to suppress every no-op update.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-06-19 16:05:31 | Re: [HACKERS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger |
Previous Message | Pavel Stehule | 2017-06-19 15:56:22 | Re: BUG #14714: long running sessions from remote instance seems to hang some times |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-06-19 16:04:13 | Re: Decimal64 and Decimal128 |
Previous Message | Robert Haas | 2017-06-19 15:49:22 | Re: Preliminary results for proposed new pgindent implementation |