Re: [Postgres-xc-developers] Implementation details for BEFORE and AFTER ROW trigger support

[Nikhil S. <ni...@st...>]

Hmmm, this is going to be a pretty common scenario then.

So no option other than #1 I guess.

Regards,
Nikhils

>> Deadlocks? ISTM, we can get more lock waits because of this but I do
>> not see deadlock scenarios..
>
>
> :) Simple rule is: if DBMS is locking transaction-long resources which
> application doesn't expect, there are bound to be deadlocks.
>
> The application induced deadlocks. An application would think that statement
> A would not lock row rA because it's not being updated, but actually it gets
> locked for UPDATE because of option #2 it locks it. The same application
> would assume that statement B would not lock row rB the same way. WIth this
> context consider following sequence of events
>
> Statement A updates row rB
>
> Statement B updates row rA
>
> Statement A tries to update row rM, but XC tries to lock rA (because of
> option #2) and waits
>
> Statement B tries to update row rN, but XC tries to lock rB (because of
> option #2) and waits
>
> None of A and B can proceed and thus deadlock, even if the application
> doesn't expect those to deadlock.
>
>>
>>
>> With the FQS shipping work being done by Ashutosh, will we also ship
>> major chunks of subplans to the datanodes? If yes, then row locking
>> will only involve required tuples (hopefully) from the coordinator's
>> point of view.
>>
>
> The push-down will work only when there shippable subplans, but if they are
> not ...
>
>>
>> Also, something radical is can be invent a new type of FOR [NODE]
>> UPDATE type lock to minimize the impact of such locking of rows on
>> datanodes?
>>
>> Regards,
>> Nikhils
>>
>> >>
>> >> 3.  The BEFORE trigger function can change the distribution column
>> >> itself. We need to add a check at the end of the trigger executions.
>> >>
>> >
>> > Good, you thought about that. Yes we should check it.
>> >
>> >>
>> >> 4. Fetching OLD row for WHEN clause handling.
>> >>
>> >> 5. Testing with mix of Shippable and non-shippable ROW triggers
>> >>
>> >> 6. Other types of triggers. INSTEAD triggers are anticipated to work
>> >> without significant changes, but they are yet to be tested.
>> >> INSERT/DELETE triggers: Most of the infrastructure has been done while
>> >> implementing UPDATE triggers. But some changes specific to INSERT and
>> >> DELETE are yet to be done.
>> >> Deferred triggers to be tested.
>> >>
>> >> 7. Regression analysis. There are some new failures. Will post another
>> >> fair version of the patch after regression analysis and fixing various
>> >> TODOs.
>> >>
>> >> Comments welcome.
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Everyone hates slow websites. So do we.
>> >> Make your web apps faster with AppDynamics
>> >> Download AppDynamics Lite for free today:
>> >> http://p.sf.net/sfu/appdyn_d2d_feb
>> >> _______________________________________________
>> >> Postgres-xc-developers mailing list
>> >> Pos...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> >>
>> >
>> >
>> >
>> > --
>> > Best Wishes,
>> > Ashutosh Bapat
>> > EntepriseDB Corporation
>> > The Enterprise Postgres Company
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Everyone hates slow websites. So do we.
>> > Make your web apps faster with AppDynamics
>> > Download AppDynamics Lite for free today:
>> > http://p.sf.net/sfu/appdyn_d2d_feb
>> > _______________________________________________
>> > Postgres-xc-developers mailing list
>> > Pos...@li...
>> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> >
>>
>>
>>
>> --
>> StormDB - http://www.stormdb.com
>> The Database Cloud
>> Postgres-XC Support and Service
>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company



-- 
StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Service