Re: UPDATE of partition key
Amit Khandekar <amitdkhan.pg@gmail.com>
Attachments
- update-partition-key_v17.patch (application/octet-stream) patch v17
On 6 September 2017 at 21:47, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> On Mon, Sep 4, 2017 at 10:52 AM, Amit Khandekar <amitdkhan.pg@gmail.com> wrote:
>> On 4 September 2017 at 07:43, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> Oops sorry. Now attached.
>
> I have done some basic testing and initial review of the patch. I
Thanks for taking this up for review. Attached is the updated patch
v17, that covers the below points.
> + if (mtstate->operation == CMD_UPDATE && mtstate->mt_transition_capture)
> + ExecARUpdateTriggers(estate, resultRelInfo, InvalidOid,
>
> For passing invalid ItemPointer we are using InvalidOid, this seems
> bit odd to me
> are we using simmilar convention some other place? I think it would be better to
> just pass 0?
Yes that's right. Replaced InvalidOid by NULL since ItemPointer is a pointer.
>
> ------
>
> - if ((event == TRIGGER_EVENT_DELETE && delete_old_table) ||
> - (event == TRIGGER_EVENT_UPDATE && update_old_table))
> + if (oldtup != NULL &&
> + ((event == TRIGGER_EVENT_DELETE && delete_old_table) ||
> + (event == TRIGGER_EVENT_UPDATE && update_old_table)))
> {
> Tuplestorestate *old_tuplestore;
>
> - Assert(oldtup != NULL);
>
> Only if TRIGGER_EVENT_UPDATE it is possible that oldtup can be NULL,
> so we have added an extra
> check for oldtup and removed the Assert, but if TRIGGER_EVENT_DELETE
> we never expect it to be NULL.
>
> Is it better to put Assert outside the condition check (Assert(oldtup
> != NULL || event == TRIGGER_EVENT_UPDATE)) ?
> same for the newtup.
>
> I think we should also explain in comments about why oldtup or newtup
> can be NULL in case of if
> TRIGGER_EVENT_UPDATE
Done all the above. Added two separate asserts, one for DELETE and the
other for INSERT.
>
> -------
>
> + triggers affect the row being moved. As far as <literal>AFTER ROW</>
> + triggers are concerned, <literal>AFTER</> <command>DELETE</command> and
> + <literal>AFTER</> <command>INSERT</command> triggers are applied; but
> + <literal>AFTER</> <command>UPDATE</command> triggers are not applied
> + because the <command>UPDATE</command> has been converted to a
> + <command>DELETE</command> and <command>INSERT</command>.
>
> Above comments says that ARUpdate trigger is not fired but below code call
> ARUpdateTrigger
>
> + if (mtstate->operation == CMD_UPDATE && mtstate->mt_transition_capture)
> + ExecARUpdateTriggers(estate, resultRelInfo, InvalidOid,
> + NULL,
> + tuple,
> + NULL,
> + mtstate->mt_transition_capture);
Actually, since transition tables came in, the functions like
ExecARUpdateTriggers() or ExecARInsertTriggers() have this additional
purpose of capturing transition table rows, so that the images of the
tables are visible when statement triggers are fired that refer to
these transition tables. So in the above code, these functions only
capture rows, they do not add any event for firing any ROW triggers.
AfterTriggerSaveEvent() returns without adding any event if it's
called only for transition capture. So even if UPDATE row triggers are
defined, they won't get fired in case of row movement, although the
updated rows would be captured if transition tables are referenced in
these triggers or in the statement triggers.
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
Commits
-
Avoid referencing off the end of subplan_partition_offsets.
- 945f71db8452 11.0 landed
-
Allow UPDATE to move rows between partitions.
- 2f178441044b 11.0 landed
-
Remove useless lookup of root partitioned rel in ExecInitModifyTable().
- dca48d145e0e 11.0 cited
-
Factor error generation out of ExecPartitionCheck.
- 19c47e7c8202 11.0 landed
-
Minor preparatory refactoring for UPDATE row movement.
- ef6087ee5fa8 11.0 landed
-
Simplify and encapsulate tuple routing support code.
- cc6337d2fed5 11.0 landed
-
Avoid coercing a whole-row variable that is already coerced.
- 1c497fa72df7 11.0 landed
-
Use ResultRelInfo ** rather than ResultRelInfo * for tuple routing.
- 60f7c0abef03 11.0 landed
-
Make RelationGetPartitionDispatchInfo expand depth-first.
- 77b6b5e9ceca 11.0 cited
-
Expand partitioned tables in PartDesc order.
- 30833ba154e0 11.0 cited
-
Use a real RT index when setting up partition tuple routing.
- f81a91db4d1c 10.0 cited
-
Fix transition tables for partition/inheritance.
- 501ed02cf6f4 10.0 cited
-
Fix confusion about number of subplans in partitioned INSERT setup.
- 78a030a44196 10.0 cited
-
Prevent BEFORE triggers from violating partitioning constraints.
- 15ce775faa42 10.0 cited
-
Fire per-statement triggers on partitioned tables.
- e180c8aa8caf 10.0 cited
-
Fix reporting of violations in ExecConstraints, again.
- c0a8ae7be392 10.0 cited
-
Don't scan partitioned tables.
- d3cc37f1d801 10.0 cited
-
Allow FDWs to push down quals without breaking EvalPlanQual rechecks.
- 5fc4c26db512 9.6.0 cited