From: Ashutosh B. <ash...@en...> - 2013-05-13 09:07:02
|
Hi Amit, We now have Query structure in RemoteQuery. This corresponds to the query being fired on the datanodes. THe commandType here should tell you whether it's DELETE or not. On Mon, May 13, 2013 at 1:14 PM, Amit Khandekar < ami...@en...> wrote: > In case of multiple triggers of the same type for a given table, the > requirement is that they should be fired in alphabetical order. To do so, > we need to fire either all of them on coordinator, or all of them on > datanode. The main changes in the attached patch are related to this > requirement. > > All of the Exec*Trigger() functions now execute should_exec_trigger*() > functions that return true if the node on which they are run is the right > node to execute those type of triggers. > > Also for BR triggers, the additional requirement is that they should be > run on coordinator if AR triggers are not shippable, regardless of whether > BR themselves are shippable or not. This is because, if we fire BR triggers > on datanode, they might change the final row updated, and so we need to > again fetch the new row back to the coordinator. Instead, if we fire them > on coordinator, we already know what's the final row. Also, we would have > required additional changes to add RETURNING to the remote query to fetch > the final updated row. > > Constraint triggers are exception; we need to fire them always on > datanode. Once we support global constraints, these need not be specially > handled. > > I was trying to avoid the should_exec_trigger*() calls for each of the > Exec*Trigger() functions by doing this in TriggerEnabled() because it is a > common function called for all triggers. But the issue is, for AFTER > triggers, it is called with a different set of event type values than the > usual TRIGGER_TYPE* values. For AFTER triggers, TRIGGER_EVENT_* values are > used. Anyways, TriggerEnabled() is called for each of the trigger. > > The trigger shippability helper functions are now completely changed. > pgxc_find_nonshippable_row_trig() is the key function. The comments in > these functions should give a fair idea of their functionality. > > > For stmt shippability, the trigger functions are now explicitly called if > it's not an internally generated query. rq_internal_params field is used to > know that this DML is user-supplied query (that is, it would be FQS). The > functions are called in RemoteQueryNext(). > > > THere is another patch (relaccess_type.patch) that you need to first apply > before the main patch (trig_shippability.patch) is applied. I had to add > another RELATION_ACCESS_DELETE in ExecNodes. To handle the stmt triggers, I > had to know whether the statement is DELETE or INSERT or UPDATE. > > The new test xc_trigship is added. > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Postgres Database Company |