postgres-xc-developers Mailing List for Postgres-XC

Year.   I agree.
----------
Koichi Suzuki



2011/8/8 Ashutosh Bapat <ash...@en...>:
>
>
> On Mon, Aug 8, 2011 at 11:31 AM, Koichi Suzuki <koi...@gm...> wrote:
>>
>> I understand it's a bit complicated in the case of replicated tables.
>>  To start with, I think we can leave all the side effect to user's
>> responsibility.    User's can issue DML which may lead to inconsistent
>> replica status.   Which will in tern lead to inconsistent result in
>> future statements.
>
> In this case, we should at least be able to find out whether a DML is
> harmful or not and given user a warning. Otherwise, it will be difficult for
> users to know what caused the inconsistency in the data?
>
>>
>> I think this is what we should compromise (although everybody wants to
>> avoid).
>>
>> Any further inputs?
>> ----------
>> Koichi Suzuki
>>
>>
>>
>> 2011/8/8 Michael Paquier <mic...@gm...>:
>> > Hi all,
>> >
>> > I am having a look at triggers, and here is my thoughts as far. I
>> > remember
>> > that we decided to fire only triggers on Datanodes, but I really doubt
>> > this
>> > is enough.
>> > Triggers are basically fired in two cases, for each row or for each
>> > statement.
>> >
>> > About FOR EACH STATEMENT:
>> > This is the default, this setting fires a trigger each time a statement
>> > is
>> > launched.
>> > In XC architecture, a Coordinator master launches the query, so doesn't
>> > this
>> > implicitly means that this kind of trigger should be fired on
>> > Coordinators?
>> > Then Coordinator is in charge to transmit to Datanodes the order to fire
>> > this trigger?
>> >
>> > About FOR EACH ROW:
>> > This is the case when a trigger is fired each time something happens on
>> > a
>> > table row.
>> > As Datanodes are the only nodes to hold table data, I suppose it is
>> > enough
>> > to fire triggers on Datanodes to check constraints. However, this is
>> > more
>> > complicated when triggers themselves do DML actions.
>> > For example, if a trigger is fired on a replicated table, and let's
>> > imagine
>> > that this trigger updates a timestamp on an other replicated table after
>> > a
>> > DML event, I am afraid that the timestamp value updated will not be
>> > consistent among the cluster if trigger is only fired on Datanodes.
>> > This becomes even more complicated when a trigger does an insert on a
>> > table
>> > whose column uses a default value from a non-immutable function (@-@)
>> >
>> > For the time being, I am thinking that it may be enough to support
>> > triggers
>> > fired for each statements, and that those triggers will be fired on
>> > Coordinators.
>> > Moreover, it is necessary to think about a mechanism to activate
>> > triggers
>> > from a Coordinator to Datanodes (for both events before/after).
>> >
>> > Thoughts?
>> > --
>> > Michael Paquier
>> > http://michael.otacoo.com
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
>> > The must-attend event for mobile developers. Connect with experts.
>> > Get tools for creating Super Apps. See the latest technologies.
>> > Sessions, hands-on labs, demos & much more. Register early & save!
>> > http://p.sf.net/sfu/rim-blackberry-1
>> > _______________________________________________
>> > Postgres-xc-developers mailing list
>> > Pos...@li...
>> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> >
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
>> The must-attend event for mobile developers. Connect with experts.
>> Get tools for creating Super Apps. See the latest technologies.
>> Sessions, hands-on labs, demos & much more. Register early & save!
>> http://p.sf.net/sfu/rim-blackberry-1
>> _______________________________________________
>> 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
>
>

On Mon, Aug 8, 2011 at 11:31 AM, Koichi Suzuki <koi...@gm...> wrote:

> I understand it's a bit complicated in the case of replicated tables.
>  To start with, I think we can leave all the side effect to user's
> responsibility.    User's can issue DML which may lead to inconsistent
> replica status.   Which will in tern lead to inconsistent result in
> future statements.
>

In this case, we should at least be able to find out whether a DML is
harmful or not and given user a warning. Otherwise, it will be difficult for
users to know what caused the inconsistency in the data?


>
> I think this is what we should compromise (although everybody wants to
> avoid).
>
> Any further inputs?
> ----------
> Koichi Suzuki
>
>
>
> 2011/8/8 Michael Paquier <mic...@gm...>:
> > Hi all,
> >
> > I am having a look at triggers, and here is my thoughts as far. I
> remember
> > that we decided to fire only triggers on Datanodes, but I really doubt
> this
> > is enough.
> > Triggers are basically fired in two cases, for each row or for each
> > statement.
> >
> > About FOR EACH STATEMENT:
> > This is the default, this setting fires a trigger each time a statement
> is
> > launched.
> > In XC architecture, a Coordinator master launches the query, so doesn't
> this
> > implicitly means that this kind of trigger should be fired on
> Coordinators?
> > Then Coordinator is in charge to transmit to Datanodes the order to fire
> > this trigger?
> >
> > About FOR EACH ROW:
> > This is the case when a trigger is fired each time something happens on a
> > table row.
> > As Datanodes are the only nodes to hold table data, I suppose it is
> enough
> > to fire triggers on Datanodes to check constraints. However, this is more
> > complicated when triggers themselves do DML actions.
> > For example, if a trigger is fired on a replicated table, and let's
> imagine
> > that this trigger updates a timestamp on an other replicated table after
> a
> > DML event, I am afraid that the timestamp value updated will not be
> > consistent among the cluster if trigger is only fired on Datanodes.
> > This becomes even more complicated when a trigger does an insert on a
> table
> > whose column uses a default value from a non-immutable function (@-@)
> >
> > For the time being, I am thinking that it may be enough to support
> triggers
> > fired for each statements, and that those triggers will be fired on
> > Coordinators.
> > Moreover, it is necessary to think about a mechanism to activate triggers
> > from a Coordinator to Datanodes (for both events before/after).
> >
> > Thoughts?
> > --
> > Michael Paquier
> > http://michael.otacoo.com
> >
> >
> ------------------------------------------------------------------------------
> > BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> > The must-attend event for mobile developers. Connect with experts.
> > Get tools for creating Super Apps. See the latest technologies.
> > Sessions, hands-on labs, demos & much more. Register early & save!
> > http://p.sf.net/sfu/rim-blackberry-1
> > _______________________________________________
> > Postgres-xc-developers mailing list
> > Pos...@li...
> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >
> >
>
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> 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

Thanks a lot Michael.

On Mon, Aug 8, 2011 at 5:32 AM, Michael Paquier
<mic...@gm...>wrote:

> Hi all,
>
> Please find attached a patch that fixes 90% of the code warnings.
> There are still warnings in the code, that I cannot take out due to the
> strong dependency between GTM and the rest of the code since GTM-Standby
> implementation.
> Any comments are welcome.
>
> Regards,
> --
> Michael Paquier
> http://michael.otacoo.com
>
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> 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

I understand it's a bit complicated in the case of replicated tables.
 To start with, I think we can leave all the side effect to user's
responsibility.    User's can issue DML which may lead to inconsistent
replica status.   Which will in tern lead to inconsistent result in
future statements.

I think this is what we should compromise (although everybody wants to avoid).

Any further inputs?
----------
Koichi Suzuki



2011/8/8 Michael Paquier <mic...@gm...>:
> Hi all,
>
> I am having a look at triggers, and here is my thoughts as far. I remember
> that we decided to fire only triggers on Datanodes, but I really doubt this
> is enough.
> Triggers are basically fired in two cases, for each row or for each
> statement.
>
> About FOR EACH STATEMENT:
> This is the default, this setting fires a trigger each time a statement is
> launched.
> In XC architecture, a Coordinator master launches the query, so doesn't this
> implicitly means that this kind of trigger should be fired on Coordinators?
> Then Coordinator is in charge to transmit to Datanodes the order to fire
> this trigger?
>
> About FOR EACH ROW:
> This is the case when a trigger is fired each time something happens on a
> table row.
> As Datanodes are the only nodes to hold table data, I suppose it is enough
> to fire triggers on Datanodes to check constraints. However, this is more
> complicated when triggers themselves do DML actions.
> For example, if a trigger is fired on a replicated table, and let's imagine
> that this trigger updates a timestamp on an other replicated table after a
> DML event, I am afraid that the timestamp value updated will not be
> consistent among the cluster if trigger is only fired on Datanodes.
> This becomes even more complicated when a trigger does an insert on a table
> whose column uses a default value from a non-immutable function (@-@)
>
> For the time being, I am thinking that it may be enough to support triggers
> fired for each statements, and that those triggers will be fired on
> Coordinators.
> Moreover, it is necessary to think about a mechanism to activate triggers
> from a Coordinator to Datanodes (for both events before/after).
>
> Thoughts?
> --
> Michael Paquier
> http://michael.otacoo.com
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>

Hi all,

I am having a look at triggers, and here is my thoughts as far. I remember
that we decided to fire only triggers on Datanodes, but I really doubt this
is enough.
Triggers are basically fired in two cases, for each row or for each
statement.

About FOR EACH STATEMENT:
This is the default, this setting fires a trigger each time a statement is
launched.
In XC architecture, a Coordinator master launches the query, so doesn't this
implicitly means that this kind of trigger should be fired on Coordinators?
Then Coordinator is in charge to transmit to Datanodes the order to fire
this trigger?

About FOR EACH ROW:
This is the case when a trigger is fired each time something happens on a
table row.
As Datanodes are the only nodes to hold table data, I suppose it is enough
to fire triggers on Datanodes to check constraints. However, this is more
complicated when triggers themselves do DML actions.
For example, if a trigger is fired on a replicated table, and let's imagine
that this trigger updates a timestamp on an other replicated table after a
DML event, I am afraid that the timestamp value updated will not be
consistent among the cluster if trigger is only fired on Datanodes.
This becomes even more complicated when a trigger does an insert on a table
whose column uses a default value from a non-immutable function (@-@)

For the time being, I am thinking that it may be enough to support triggers
fired for each statements, and that those triggers will be fired on
Coordinators.
Moreover, it is necessary to think about a mechanism to activate triggers
from a Coordinator to Datanodes (for both events before/after).

Thoughts?
-- 
Michael Paquier
http://michael.otacoo.com

Hi all,

Please find attached a patch that fixes 90% of the code warnings.
There are still warnings in the code, that I cannot take out due to the
strong dependency between GTM and the rest of the code since GTM-Standby
implementation.
Any comments are welcome.

Regards,
-- 
Michael Paquier
http://michael.otacoo.com