Re: Concurrency bug in UPDATE of partition-key
Amit Khandekar <amitdkhan.pg@gmail.com>
From: Amit Khandekar <amitdkhan.pg@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-06-19T16:03:44Z
Lists: pgsql-hackers
Attachments
- fix_concurrency_bug_v3.patch (application/octet-stream) patch v3
On 19 June 2018 at 13:06, Dilip Kumar <dilipbalaut@gmail.com> wrote: > On Mon, Jun 18, 2018 at 6:19 PM, Amit Khandekar <amitdkhan.pg@gmail.com> wrote: >> On 18 June 2018 at 17:56, Amit Kapila <amit.kapila16@gmail.com> wrote: >>> On Mon, Jun 18, 2018 at 11:28 AM, Dilip Kumar <dilipbalaut@gmail.com> wrote: >>>> Should we also create a test case where we can verify that some >>>> unnecessary or duplicate triggers are not executed? >>>> >>> >>> I am not sure how much value we will add by having such a test. In >>> general, it is good to have tests that cover various aspects of >>> functionality, but OTOH, we have to be careful to not overdo it. >> >> Actually I am thinking, it's not a big deal adding a RAISE statement >> in trigger function in the existing testcases. It will clearly show how >> many times the trigger has executed. So I will go ahead and do that. > > Ok, That makes sense to me. Could not add RAISE statement, because the isolation test does not seem to print those statements in the output. Instead, I have dumped some rows in a new table through the trigger function, and did a select from that table. Attached is v3 patch. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company
Commits
-
Allow using the updated tuple while moving it to a different partition.
- 40ca70ebcc9d 12.0 landed
- 0527df732beb 11.0 landed