postgres-xc-developers Mailing List for Postgres-XC

On Mon, Jul 23, 2012 at 2:17 PM, Abbas Butt <abb...@en...>wrote:

> Agreed. Please go ahead and check in this fix.

Thanks, I fixed that and also another issue I found on the way.
-- 
Michael Paquier
http://michael.otacoo.com

Agreed. Please go ahead and check in this fix.

On Mon, Jul 23, 2012 at 10:14 AM, Michael Paquier <mic...@gm...
> wrote:

> Yeah OK. Btw, it should be better to set up the entire condition inside
> this loop, checking for parent/child INSERT SELECT condition on remote
> nodes doesn't make sense either.
> if (IS_PGXC_COORDINATOR && !IsConnFromCoord())
> {
>     target_rte = rt_fetch(qry->resultRelation, pstate->p_rtable);
>     if (is_relation_child(target_rte, selectQuery->rtable))
>     {
>         qry->is_ins_child_sel_parent = true;
>         SetSendCommandId(true);
>
>     }
> }
>
> On Mon, Jul 23, 2012 at 2:05 PM, Abbas Butt <abb...@en...>wrote:
>
>> Thanks Michael, I just reviewed the patch and found one small thing.
>>
>> In the function transformInsertStmt where we set
>> SetSendCommandId(true);
>> I think it would be better to put this statement under an
>> if (IS_PGXC_COORDINATOR && !IsConnFromCoord())
>>
>> Other than that I am OK with the changes.
>>
>> Regards
>>
>>
>> On Mon, Jul 23, 2012 at 7:08 AM, Michael Paquier <
>> mic...@gm...> wrote:
>>
>>> Hi,
>>>
>>> I spent some time this morning rewriting your patch.
>>> I reduced the number of functions and parameters to a minimum number and
>>> eliminated the useless message 'Y'.
>>> 'Y' definitely doesn't make sense as it has absolutely the same role as
>>> 'M'. In the former patch, the notion of notification is simply to send a
>>> message from Coordinator to Datanode, but a Datanode can also send a GXID,
>>> snapshot and timestamp using the same message types as the one used when a
>>> Coordinator sends data to a remote node. So we shouldn't lose this
>>> portability of the new messages. The only thing that changes for
>>> Coordinator->remoteNode and remoteCode->Coordinator communication protocol
>>> is the place where message is read. in the first case, message is received
>>> by remote node in postgres.c stuff. In the second case, message is received
>>> inside execRemote.c, so this distinction makes perfectly safe the fact of
>>> using the same message 'M', making 'Y' unnecessary.
>>> Also, it is really important to limit the number of used message types
>>> to reduce the footprint of XC code on PostgreSQL.
>>>
>>> There are no problems with regressions, and performance is not impacted.
>>> I also corrected some comment format and added some other comments at
>>> various places.
>>> In consequence, and to simplify the work of everybody, I am going to
>>> commit this largely simplified version of the patch.
>>>
>>> Thanks,
>>>
>>>
>>> On Sat, Jul 21, 2012 at 6:29 PM, Abbas Butt <abb...@en...
>>> > wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jul 20, 2012 at 11:04 AM, Michael Paquier <
>>>> mic...@gm...> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Sorry for being a little bit picky here:
>>>>> 1) In GetCurrentSubTransactionId of xact.c, you can replace:
>>>>> if (IS_PGXC_DATANODE && isCommandIdReceived)
>>>>> {
>>>>>    foo
>>>>> }
>>>>> else
>>>>> {
>>>>>    if (IS_PGXC_COORDINATOR && !IsConnFromCoord())
>>>>>       re_foo
>>>>> }
>>>>> by:
>>>>> if (IS_PGXC_DATANODE && isCommandIdReceived)
>>>>> {
>>>>>    foo
>>>>> }
>>>>> else if (IS_PGXC_COORDINATOR && !IsConnFromCoord())
>>>>> {
>>>>>     re_foo
>>>>> }
>>>>>
>>>>
>>>> Done
>>>>
>>>>
>>>>> 2) I am not so much a fan of this 'Y' message as for now it just has a
>>>>> single usage, and M is doing exactly the same thing... But seen as a
>>>>> message that a remote node sends a notification to its backend, ok it makes
>>>>> some sense. In this case you should avoid to use a magic number like '1'.
>>>>> Please use a define like:
>>>>> #define DATANODE_NOTIFICATION_COMMAND_ID '1'
>>>>> A place like pgxc.h would make sense to define that.
>>>>> Then use this variable at the places where you need it
>>>>> (HandleDatanodeNotification of execRemote.c and ReportCommandIdChange of
>>>>> xact.c). It will bring more visibility to your code.
>>>>>
>>>>
>>>> Done
>>>>
>>>>
>>>>> 3) SetCmdIdSending and SetCmdIdReporting should be combined, they
>>>>> serve the same purpose. Their only difference is the node type where they
>>>>> are used. Let's make that generic. As a general name, SetCommandIdSending
>>>>> would be enough.
>>>>>
>>>>
>>>> I am not getting how to do that, consider the example of
>>>> StartTransaction function where we want to SetCmdIdReporting(false).
>>>> Suppose we combine both functions and have the new function like this
>>>>
>>>> void SetCmdIdSending(bool enb)
>>>> {
>>>>   if(IS_PGXC_COORDINATOR && !IsConnFromCoord())
>>>>     sendCommandId = enb;
>>>>   else if(IS_PGXC_DATANODE)
>>>>     sendCommandId = enb;
>>>> }
>>>>
>>>> and that we call this function instead of SetCmdIdReporting. It will
>>>> work OK for data node but when the same code executes for coordinator we
>>>> will set sendCommandId to false which was not required. Perhaps I did not
>>>> get your point.
>>>>
>>>>
>>>>> 4) GetCmdIdOfDatanode and GetCmdIdOfCoordinator should also be
>>>>> combined. They do exactly the same thing, the only difference is that one
>>>>> is launched on Datanode and the other on Coordinator. A general name like
>>>>> GetCommandIdReceived would be nicer.
>>>>>
>>>>
>>>> See my comment for point (3)
>>>>
>>>> 5) In portalcmds.c, PerformCursorOpen. You need to replace
>>>>> if (IS_PGXC_COORDINATOR)
>>>>>                GetCurrentCommandId(true);
>>>>> by:
>>>>> if (IS_PGXC_COORDINATOR && !IsConnFromCoord())
>>>>>                GetCurrentCommandId(true);
>>>>>
>>>>
>>>> Done.
>>>>
>>>>
>>>>> 6) For the regressions, I am still getting the diffs. Based on your
>>>>> test, I get this ordering for PG and XC:
>>>>> pgxc# select * from test_text order by 1;
>>>>>                  a
>>>>> ------------------------------------
>>>>>  Bancroft                      Ave
>>>>>  Bancroft                      Ave
>>>>>  Birch                         St
>>>>>  Birch                         St
>>>>>  Blacow                        Road
>>>>>  Bridgepointe                  Dr
>>>>>  Broadmore                     Ave
>>>>>  Broadway
>>>>>  B                             St
>>>>> (9 rows)
>>>>> If we are getting the same diffs we should change the output, it looks
>>>>> to be a side-effect of your fix for INSERT SELECT on parent-child,
>>>>>
>>>>
>>>> Done
>>>>
>>>>
>>>>>
>>>>> On Fri, Jul 20, 2012 at 2:15 AM, Abbas Butt <
>>>>> abb...@en...> wrote:
>>>>>
>>>>>> Attached please find the updated patch.
>>>>>>
>>>>>> On Thu, Jul 19, 2012 at 11:01 AM, Abbas Butt <
>>>>>> abb...@en...> wrote:
>>>>>>
>>>>>>> Thanks Michael for the review, Thanks Ashutosh for the comments,
>>>>>>> Michael I will accommodate your valuable feedback and will send
>>>>>>> revised patch.
>>>>>>> Ashutosh I will send the summarized design in the email with the
>>>>>>> revised patch.
>>>>>>> BTW enb is short for enable!
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jul 19, 2012 at 10:37 AM, Michael Paquier <
>>>>>>> mic...@gm...> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Finally I took some time to look at this code, it is important
>>>>>>>> support.
>>>>>>>> 1) The code is not realigned with current master (xc_misc.sql) and
>>>>>>>> contains whitespaces (2 in xc_misc.out, perhaps other files as well). So I
>>>>>>>> realigned it myself to test the code.
>>>>>>>>
>>>>>>>
>>>>>> The attached patch is aligned with the current master and I have
>>>>>> removed white spaces.
>>>>>>
>>>>>>
>>>>>>>  2) In GetCurrentCommandId xact.c, you need to set
>>>>>>>> !IsConnFromCoord() with (IS_PGXC_COORDINATOR) to avoid remote coordinators
>>>>>>>> incrementing the command ID. Remote Coordinators do not receive any command
>>>>>>>> IDs from remote nodes. Also here using an if/else if structure won't hurt
>>>>>>>> and bring clarity in the operations.
>>>>>>>>
>>>>>>>
>>>>>> Added the check and used if/else
>>>>>>
>>>>>>
>>>>>>>  3) In BeginTransactionBlock of xact.c, you need to add
>>>>>>>> !IsConnFromCoord() as a secondary condition to avoid remote Coordinator
>>>>>>>> problems.
>>>>>>>>
>>>>>>>
>>>>>> Done
>>>>>>
>>>>>>
>>>>>>> 4) By looking at the patch It is possible to reduce the number of
>>>>>>>> variables used for the control of Command ID. In the current version of
>>>>>>>> your patch, you are using 5 static variables:
>>>>>>>> static CommandId    cmdIdFromCoord;        /* Datanode will use
>>>>>>>> command id received from coordinator */
>>>>>>>> static bool        cmdIdRcvdAtDatanode;    /* Has the coordinator
>>>>>>>> sent command id to the data node? */
>>>>>>>> static bool        enbCmdIdChgReporting;    /* Should datanode
>>>>>>>> report command id changes to coordinator? */
>>>>>>>> static bool        enbCoordCmdIdSending;    /* Should coordinator
>>>>>>>> send command id to the data node? */
>>>>>>>> static CommandId    cmdIdFromDatanode;    /* Coordinator will
>>>>>>>> receive updated command id from datanode */
>>>>>>>> However, cmdIdRcvdAtDatanode, cmdIdFromCoord and
>>>>>>>> enbCmdIdChgReporting are used only at Datanode.
>>>>>>>> cmdIdFromDatanode and enbCoordCmdIdSending are only used at
>>>>>>>> Coordinator level.
>>>>>>>> You should combine enbCoordCmdIdSending and enbCmdIdChgReporting
>>>>>>>> into a single variable with a generic name, like let's say sendCommandId or
>>>>>>>> reportCommandId. Specifying in comments the role of this unique variable
>>>>>>>> for local Coordinator and remote nodes will help. Those 2 variables play
>>>>>>>> the same role which is to control if a
>>>>>>>> In the case of Coordinator, this variable is flagged to true when
>>>>>>>> transforming INSERT statements (transformInsertStmt) and when a transaction
>>>>>>>> block is begun (BeginTransactionBlock).
>>>>>>>> In the case of a Datanode, this variable is flagged to true only
>>>>>>>> when a command ID has been received from Coordinator.
>>>>>>>>
>>>>>>>>
>>>>>> Done, I used functions to retain code readability and inside the
>>>>>> functions I used the same variables as u suggested.
>>>>>>
>>>>>>
>>>>>>> Then, you should combine cmdIdFromCoord and cmdIdFromDatanode into a
>>>>>>>> single variable, like receivedCommandId. In this case, being at Coordinator
>>>>>>>> or at Datanode means that this command ID has been received from a remode
>>>>>>>> node. If you have other ideas for names please feel free!
>>>>>>>>
>>>>>>>
>>>>>> Done, again I used functions to retain code readability. I however
>>>>>> had to add checks inside the functions to make sure that the functions
>>>>>> intended for data node work only for data nodes and the ones intended for
>>>>>> coordinators work only for coordinators.
>>>>>>
>>>>>>
>>>>>>> Also changing the name cmdIdRcvdAtDatanode to isCommandIdReceived
>>>>>>>> might help...
>>>>>>>>
>>>>>>>
>>>>>> Done
>>>>>>
>>>>>>
>>>>>>> Just a question, what means the preffix enb? (just by curiosity) :)
>>>>>>>>
>>>>>>>> 5) In xact.c, at the end of CommitTransaction, PrepareTransaction,
>>>>>>>> CleanupTransaction, you will need to change the cleanup of the variables if
>>>>>>>> you take into account comment 4).
>>>>>>>>
>>>>>>>
>>>>>> Done
>>>>>>
>>>>>>
>>>>>>> 6) In BeginTransactionBlock, PrepareTransactionBlock,
>>>>>>>> EndTransactionBlock and UserAbortTransactionBlock of xact.c, you need to
>>>>>>>> set an additional !IsConnFromCoord() at this place, this will avoid remote
>>>>>>>> Coordinators trying to send CommandIds to inexistent nodes.
>>>>>>>> if(IS_PGXC_COORDINATOR)
>>>>>>>> +        SetCmdIdSending(false);
>>>>>>>>
>>>>>>>
>>>>>> Done
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> 7) You should combine the messages 'Y' and 'M'. The content and the
>>>>>>>> goals are the same. You can also eliminate the 2nd byte of 'Y' without
>>>>>>>> consequences I think.
>>>>>>>>
>>>>>>>
>>>>>> I did not combine these two. The intention of having them separate is
>>>>>> because 'Y' should not be tied to 'M', In future we might need data nodes
>>>>>> to notify coordinators of some thing else. And for the same reason I have
>>>>>> added a second byte in 'Y' so that we can have the same command notify
>>>>>> coordinators of some thing else.
>>>>>>
>>>>>>
>>>>>>> 8) Why didn't you put the reception of message 'M' in PostgresMain
>>>>>>>> of postgres.c at the same place as the reception of GXID, snapshot,
>>>>>>>> timestamp, etc.
>>>>>>>> Putting the reception of message at the end of SocketBackend makes
>>>>>>>> the code kind of inconsistent. If you keep it inside SocketBackend, you
>>>>>>>> should at least manage the message inside the switch, however I do not see
>>>>>>>> any particular reason why you receive this message in SocketBackend and not
>>>>>>>> in PostgresMain. So anything I should know?
>>>>>>>> You should also remove the flag IS_PGXC_DATANODE when receiving the
>>>>>>>> command ID. Remote Coordinator might need to be able to receive command IDs
>>>>>>>> as well, even if there is no direct usage now, but for stuff like triggers??
>>>>>>>>
>>>>>>>
>>>>>> Done, I added handling of 'M' in PostgresMain.
>>>>>>
>>>>>>
>>>>>>>  9) I found some diffs with the test select_views. It might be worth
>>>>>>>> to look at what is happening. It is perhaps an environment-related issue.
>>>>>>>> Btw, my regression diffs are attached.
>>>>>>>>
>>>>>>>
>>>>>> I was also getting these diffs but it was difficult for me to think
>>>>>> that the changes I did could cause a change in oder of rows. Here is what I
>>>>>> did to dig the issue deeper.
>>>>>>
>>>>>> create table test_text(a text);
>>>>>>
>>>>>> insert into test_text values('Bancroft                      Ave');
>>>>>> insert into test_text values('Bancroft                      Ave');
>>>>>> insert into test_text values('Birch                         St');
>>>>>> insert into test_text values('Birch                         St');
>>>>>> insert into test_text values('Blacow                        Road');
>>>>>> insert into test_text values('Bridgepointe                  Dr');
>>>>>> insert into test_text values('Broadmore                     Ave');
>>>>>> insert into test_text values('Broadway                          ');
>>>>>> insert into test_text values('B                             St');
>>>>>>
>>>>>> select * from test_text order by 1
>>>>>> produces same results with plain PG and XC
>>>>>>
>>>>>> Also I changed the query in plain PG select_views test case to
>>>>>> SELECT * FROM street ORDER BY name,cname,thepath::text;
>>>>>> and obtained same results with plain PG and XC.
>>>>>>
>>>>>> I am not sure why the test case was passing earlier with the current
>>>>>> possible expected outputs.
>>>>>>
>>>>>> Summarized design notes are attached with the mail for reference.
>>>>>>
>>>>>>  10) The modifications you are bringing to combocid_1.out are
>>>>>>>> consistent with postgres, cool!
>>>>>>>>
>>>>>>>> No performance impact with this patch! Tested and approved. This is
>>>>>>>> good.
>>>>>>>> No regression impact with this patch.
>>>>>>>>
>>>>>>>> So, to conclude, I think it is a good piece of work, really cool
>>>>>>>> stuff that I believe will be helpful for triggers and even other things.
>>>>>>>> It just needs to be polished and simplified a bit. However basics
>>>>>>>> are here, and performance is not impacted. Really it was worth spending
>>>>>>>> time on that. The additional test cases also look to be sufficient, but I
>>>>>>>> might be missing smth so feel free to add new tests if necessary.
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> --
>>>>>>>> Michael Paquier
>>>>>>>> http://michael.otacoo.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> --
>>>>>>> Abbas
>>>>>>> Architect
>>>>>>> EnterpriseDB Corporation
>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>
>>>>>>> Phone: 92-334-5100153
>>>>>>>
>>>>>>> Website: www.enterprisedb.com
>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>>>
>>>>>>> This e-mail message (and any attachment) is intended for the use of
>>>>>>> the individual or entity to whom it is addressed. This message
>>>>>>> contains information from EnterpriseDB Corporation that may be
>>>>>>> privileged, confidential, or exempt from disclosure under applicable
>>>>>>> law. If you are not the intended recipient or authorized to receive
>>>>>>> this for the intended recipient, any use, dissemination,
>>>>>>> distribution,
>>>>>>> retention, archiving, or copying of this communication is strictly
>>>>>>> prohibited. If you have received this e-mail in error, please notify
>>>>>>> the sender immediately by reply e-mail and delete this message.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> Abbas
>>>>>> Architect
>>>>>> EnterpriseDB Corporation
>>>>>> The Enterprise PostgreSQL Company
>>>>>>
>>>>>> Phone: 92-334-5100153
>>>>>>
>>>>>> Website: www.enterprisedb.com
>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>>
>>>>>> This e-mail message (and any attachment) is intended for the use of
>>>>>> the individual or entity to whom it is addressed. This message
>>>>>> contains information from EnterpriseDB Corporation that may be
>>>>>> privileged, confidential, or exempt from disclosure under applicable
>>>>>> law. If you are not the intended recipient or authorized to receive
>>>>>> this for the intended recipient, any use, dissemination, distribution,
>>>>>> retention, archiving, or copying of this communication is strictly
>>>>>> prohibited. If you have received this e-mail in error, please notify
>>>>>> the sender immediately by reply e-mail and delete this message.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Paquier
>>>>> http://michael.otacoo.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Abbas
>>>> Architect
>>>> EnterpriseDB Corporation
>>>> The Enterprise PostgreSQL Company
>>>>
>>>> Phone: 92-334-5100153
>>>>
>>>> Website: www.enterprisedb.com
>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>
>>>> This e-mail message (and any attachment) is intended for the use of
>>>> the individual or entity to whom it is addressed. This message
>>>> contains information from EnterpriseDB Corporation that may be
>>>> privileged, confidential, or exempt from disclosure under applicable
>>>> law. If you are not the intended recipient or authorized to receive
>>>> this for the intended recipient, any use, dissemination, distribution,
>>>> retention, archiving, or copying of this communication is strictly
>>>> prohibited. If you have received this e-mail in error, please notify
>>>> the sender immediately by reply e-mail and delete this message.
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Paquier
>>> http://michael.otacoo.com
>>>
>>
>>
>>
>> --
>> --
>> Abbas
>> Architect
>> EnterpriseDB Corporation
>> The Enterprise PostgreSQL Company
>>
>> Phone: 92-334-5100153
>>
>> Website: www.enterprisedb.com
>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>
>> This e-mail message (and any attachment) is intended for the use of
>> the individual or entity to whom it is addressed. This message
>> contains information from EnterpriseDB Corporation that may be
>> privileged, confidential, or exempt from disclosure under applicable
>> law. If you are not the intended recipient or authorized to receive
>> this for the intended recipient, any use, dissemination, distribution,
>> retention, archiving, or copying of this communication is strictly
>> prohibited. If you have received this e-mail in error, please notify
>> the sender immediately by reply e-mail and delete this message.
>>
>
>
>
> --
> Michael Paquier
> http://michael.otacoo.com
>



-- 
--
Abbas
Architect
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: 92-334-5100153

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

Yeah OK. Btw, it should be better to set up the entire condition inside
this loop, checking for parent/child INSERT SELECT condition on remote
nodes doesn't make sense either.
if (IS_PGXC_COORDINATOR && !IsConnFromCoord())
{
    target_rte = rt_fetch(qry->resultRelation, pstate->p_rtable);
    if (is_relation_child(target_rte, selectQuery->rtable))
    {
        qry->is_ins_child_sel_parent = true;
        SetSendCommandId(true);
    }
}

On Mon, Jul 23, 2012 at 2:05 PM, Abbas Butt <abb...@en...>wrote:

> Thanks Michael, I just reviewed the patch and found one small thing.
>
> In the function transformInsertStmt where we set
> SetSendCommandId(true);
> I think it would be better to put this statement under an
> if (IS_PGXC_COORDINATOR && !IsConnFromCoord())
>
> Other than that I am OK with the changes.
>
> Regards
>
>
> On Mon, Jul 23, 2012 at 7:08 AM, Michael Paquier <
> mic...@gm...> wrote:
>
>> Hi,
>>
>> I spent some time this morning rewriting your patch.
>> I reduced the number of functions and parameters to a minimum number and
>> eliminated the useless message 'Y'.
>> 'Y' definitely doesn't make sense as it has absolutely the same role as
>> 'M'. In the former patch, the notion of notification is simply to send a
>> message from Coordinator to Datanode, but a Datanode can also send a GXID,
>> snapshot and timestamp using the same message types as the one used when a
>> Coordinator sends data to a remote node. So we shouldn't lose this
>> portability of the new messages. The only thing that changes for
>> Coordinator->remoteNode and remoteCode->Coordinator communication protocol
>> is the place where message is read. in the first case, message is received
>> by remote node in postgres.c stuff. In the second case, message is received
>> inside execRemote.c, so this distinction makes perfectly safe the fact of
>> using the same message 'M', making 'Y' unnecessary.
>> Also, it is really important to limit the number of used message types to
>> reduce the footprint of XC code on PostgreSQL.
>>
>> There are no problems with regressions, and performance is not impacted.
>> I also corrected some comment format and added some other comments at
>> various places.
>> In consequence, and to simplify the work of everybody, I am going to
>> commit this largely simplified version of the patch.
>>
>> Thanks,
>>
>>
>> On Sat, Jul 21, 2012 at 6:29 PM, Abbas Butt <abb...@en...>wrote:
>>
>>>
>>>
>>> On Fri, Jul 20, 2012 at 11:04 AM, Michael Paquier <
>>> mic...@gm...> wrote:
>>>
>>>> Hi,
>>>>
>>>> Sorry for being a little bit picky here:
>>>> 1) In GetCurrentSubTransactionId of xact.c, you can replace:
>>>> if (IS_PGXC_DATANODE && isCommandIdReceived)
>>>> {
>>>>    foo
>>>> }
>>>> else
>>>> {
>>>>    if (IS_PGXC_COORDINATOR && !IsConnFromCoord())
>>>>       re_foo
>>>> }
>>>> by:
>>>> if (IS_PGXC_DATANODE && isCommandIdReceived)
>>>> {
>>>>    foo
>>>> }
>>>> else if (IS_PGXC_COORDINATOR && !IsConnFromCoord())
>>>> {
>>>>     re_foo
>>>> }
>>>>
>>>
>>> Done
>>>
>>>
>>>> 2) I am not so much a fan of this 'Y' message as for now it just has a
>>>> single usage, and M is doing exactly the same thing... But seen as a
>>>> message that a remote node sends a notification to its backend, ok it makes
>>>> some sense. In this case you should avoid to use a magic number like '1'.
>>>> Please use a define like:
>>>> #define DATANODE_NOTIFICATION_COMMAND_ID '1'
>>>> A place like pgxc.h would make sense to define that.
>>>> Then use this variable at the places where you need it
>>>> (HandleDatanodeNotification of execRemote.c and ReportCommandIdChange of
>>>> xact.c). It will bring more visibility to your code.
>>>>
>>>
>>> Done
>>>
>>>
>>>> 3) SetCmdIdSending and SetCmdIdReporting should be combined, they serve
>>>> the same purpose. Their only difference is the node type where they are
>>>> used. Let's make that generic. As a general name, SetCommandIdSending would
>>>> be enough.
>>>>
>>>
>>> I am not getting how to do that, consider the example of
>>> StartTransaction function where we want to SetCmdIdReporting(false).
>>> Suppose we combine both functions and have the new function like this
>>>
>>> void SetCmdIdSending(bool enb)
>>> {
>>>   if(IS_PGXC_COORDINATOR && !IsConnFromCoord())
>>>     sendCommandId = enb;
>>>   else if(IS_PGXC_DATANODE)
>>>     sendCommandId = enb;
>>> }
>>>
>>> and that we call this function instead of SetCmdIdReporting. It will
>>> work OK for data node but when the same code executes for coordinator we
>>> will set sendCommandId to false which was not required. Perhaps I did not
>>> get your point.
>>>
>>>
>>>> 4) GetCmdIdOfDatanode and GetCmdIdOfCoordinator should also be
>>>> combined. They do exactly the same thing, the only difference is that one
>>>> is launched on Datanode and the other on Coordinator. A general name like
>>>> GetCommandIdReceived would be nicer.
>>>>
>>>
>>> See my comment for point (3)
>>>
>>> 5) In portalcmds.c, PerformCursorOpen. You need to replace
>>>> if (IS_PGXC_COORDINATOR)
>>>>                GetCurrentCommandId(true);
>>>> by:
>>>> if (IS_PGXC_COORDINATOR && !IsConnFromCoord())
>>>>                GetCurrentCommandId(true);
>>>>
>>>
>>> Done.
>>>
>>>
>>>> 6) For the regressions, I am still getting the diffs. Based on your
>>>> test, I get this ordering for PG and XC:
>>>> pgxc# select * from test_text order by 1;
>>>>                  a
>>>> ------------------------------------
>>>>  Bancroft                      Ave
>>>>  Bancroft                      Ave
>>>>  Birch                         St
>>>>  Birch                         St
>>>>  Blacow                        Road
>>>>  Bridgepointe                  Dr
>>>>  Broadmore                     Ave
>>>>  Broadway
>>>>  B                             St
>>>> (9 rows)
>>>> If we are getting the same diffs we should change the output, it looks
>>>> to be a side-effect of your fix for INSERT SELECT on parent-child,
>>>>
>>>
>>> Done
>>>
>>>
>>>>
>>>> On Fri, Jul 20, 2012 at 2:15 AM, Abbas Butt <
>>>> abb...@en...> wrote:
>>>>
>>>>> Attached please find the updated patch.
>>>>>
>>>>> On Thu, Jul 19, 2012 at 11:01 AM, Abbas Butt <
>>>>> abb...@en...> wrote:
>>>>>
>>>>>> Thanks Michael for the review, Thanks Ashutosh for the comments,
>>>>>> Michael I will accommodate your valuable feedback and will send
>>>>>> revised patch.
>>>>>> Ashutosh I will send the summarized design in the email with the
>>>>>> revised patch.
>>>>>> BTW enb is short for enable!
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 19, 2012 at 10:37 AM, Michael Paquier <
>>>>>> mic...@gm...> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Finally I took some time to look at this code, it is important
>>>>>>> support.
>>>>>>> 1) The code is not realigned with current master (xc_misc.sql) and
>>>>>>> contains whitespaces (2 in xc_misc.out, perhaps other files as well). So I
>>>>>>> realigned it myself to test the code.
>>>>>>>
>>>>>>
>>>>> The attached patch is aligned with the current master and I have
>>>>> removed white spaces.
>>>>>
>>>>>
>>>>>>  2) In GetCurrentCommandId xact.c, you need to set !IsConnFromCoord()
>>>>>>> with (IS_PGXC_COORDINATOR) to avoid remote coordinators incrementing the
>>>>>>> command ID. Remote Coordinators do not receive any command IDs from remote
>>>>>>> nodes. Also here using an if/else if structure won't hurt and bring clarity
>>>>>>> in the operations.
>>>>>>>
>>>>>>
>>>>> Added the check and used if/else
>>>>>
>>>>>
>>>>>>  3) In BeginTransactionBlock of xact.c, you need to add
>>>>>>> !IsConnFromCoord() as a secondary condition to avoid remote Coordinator
>>>>>>> problems.
>>>>>>>
>>>>>>
>>>>> Done
>>>>>
>>>>>
>>>>>> 4) By looking at the patch It is possible to reduce the number of
>>>>>>> variables used for the control of Command ID. In the current version of
>>>>>>> your patch, you are using 5 static variables:
>>>>>>> static CommandId    cmdIdFromCoord;        /* Datanode will use
>>>>>>> command id received from coordinator */
>>>>>>> static bool        cmdIdRcvdAtDatanode;    /* Has the coordinator
>>>>>>> sent command id to the data node? */
>>>>>>> static bool        enbCmdIdChgReporting;    /* Should datanode
>>>>>>> report command id changes to coordinator? */
>>>>>>> static bool        enbCoordCmdIdSending;    /* Should coordinator
>>>>>>> send command id to the data node? */
>>>>>>> static CommandId    cmdIdFromDatanode;    /* Coordinator will
>>>>>>> receive updated command id from datanode */
>>>>>>> However, cmdIdRcvdAtDatanode, cmdIdFromCoord and
>>>>>>> enbCmdIdChgReporting are used only at Datanode.
>>>>>>> cmdIdFromDatanode and enbCoordCmdIdSending are only used at
>>>>>>> Coordinator level.
>>>>>>> You should combine enbCoordCmdIdSending and enbCmdIdChgReporting
>>>>>>> into a single variable with a generic name, like let's say sendCommandId or
>>>>>>> reportCommandId. Specifying in comments the role of this unique variable
>>>>>>> for local Coordinator and remote nodes will help. Those 2 variables play
>>>>>>> the same role which is to control if a
>>>>>>> In the case of Coordinator, this variable is flagged to true when
>>>>>>> transforming INSERT statements (transformInsertStmt) and when a transaction
>>>>>>> block is begun (BeginTransactionBlock).
>>>>>>> In the case of a Datanode, this variable is flagged to true only
>>>>>>> when a command ID has been received from Coordinator.
>>>>>>>
>>>>>>>
>>>>> Done, I used functions to retain code readability and inside the
>>>>> functions I used the same variables as u suggested.
>>>>>
>>>>>
>>>>>> Then, you should combine cmdIdFromCoord and cmdIdFromDatanode into a
>>>>>>> single variable, like receivedCommandId. In this case, being at Coordinator
>>>>>>> or at Datanode means that this command ID has been received from a remode
>>>>>>> node. If you have other ideas for names please feel free!
>>>>>>>
>>>>>>
>>>>> Done, again I used functions to retain code readability. I however had
>>>>> to add checks inside the functions to make sure that the functions intended
>>>>> for data node work only for data nodes and the ones intended for
>>>>> coordinators work only for coordinators.
>>>>>
>>>>>
>>>>>> Also changing the name cmdIdRcvdAtDatanode to isCommandIdReceived
>>>>>>> might help...
>>>>>>>
>>>>>>
>>>>> Done
>>>>>
>>>>>
>>>>>> Just a question, what means the preffix enb? (just by curiosity) :)
>>>>>>>
>>>>>>> 5) In xact.c, at the end of CommitTransaction, PrepareTransaction,
>>>>>>> CleanupTransaction, you will need to change the cleanup of the variables if
>>>>>>> you take into account comment 4).
>>>>>>>
>>>>>>
>>>>> Done
>>>>>
>>>>>
>>>>>> 6) In BeginTransactionBlock, PrepareTransactionBlock,
>>>>>>> EndTransactionBlock and UserAbortTransactionBlock of xact.c, you need to
>>>>>>> set an additional !IsConnFromCoord() at this place, this will avoid remote
>>>>>>> Coordinators trying to send CommandIds to inexistent nodes.
>>>>>>> if(IS_PGXC_COORDINATOR)
>>>>>>> +        SetCmdIdSending(false);
>>>>>>>
>>>>>>
>>>>> Done
>>>>>
>>>>>
>>>>>>
>>>>>>> 7) You should combine the messages 'Y' and 'M'. The content and the
>>>>>>> goals are the same. You can also eliminate the 2nd byte of 'Y' without
>>>>>>> consequences I think.
>>>>>>>
>>>>>>
>>>>> I did not combine these two. The intention of having them separate is
>>>>> because 'Y' should not be tied to 'M', In future we might need data nodes
>>>>> to notify coordinators of some thing else. And for the same reason I have
>>>>> added a second byte in 'Y' so that we can have the same command notify
>>>>> coordinators of some thing else.
>>>>>
>>>>>
>>>>>> 8) Why didn't you put the reception of message 'M' in PostgresMain of
>>>>>>> postgres.c at the same place as the reception of GXID, snapshot, timestamp,
>>>>>>> etc.
>>>>>>> Putting the reception of message at the end of SocketBackend makes
>>>>>>> the code kind of inconsistent. If you keep it inside SocketBackend, you
>>>>>>> should at least manage the message inside the switch, however I do not see
>>>>>>> any particular reason why you receive this message in SocketBackend and not
>>>>>>> in PostgresMain. So anything I should know?
>>>>>>> You should also remove the flag IS_PGXC_DATANODE when receiving the
>>>>>>> command ID. Remote Coordinator might need to be able to receive command IDs
>>>>>>> as well, even if there is no direct usage now, but for stuff like triggers??
>>>>>>>
>>>>>>
>>>>> Done, I added handling of 'M' in PostgresMain.
>>>>>
>>>>>
>>>>>>  9) I found some diffs with the test select_views. It might be worth
>>>>>>> to look at what is happening. It is perhaps an environment-related issue.
>>>>>>> Btw, my regression diffs are attached.
>>>>>>>
>>>>>>
>>>>> I was also getting these diffs but it was difficult for me to think
>>>>> that the changes I did could cause a change in oder of rows. Here is what I
>>>>> did to dig the issue deeper.
>>>>>
>>>>> create table test_text(a text);
>>>>>
>>>>> insert into test_text values('Bancroft                      Ave');
>>>>> insert into test_text values('Bancroft                      Ave');
>>>>> insert into test_text values('Birch                         St');
>>>>> insert into test_text values('Birch                         St');
>>>>> insert into test_text values('Blacow                        Road');
>>>>> insert into test_text values('Bridgepointe                  Dr');
>>>>> insert into test_text values('Broadmore                     Ave');
>>>>> insert into test_text values('Broadway                          ');
>>>>> insert into test_text values('B                             St');
>>>>>
>>>>> select * from test_text order by 1
>>>>> produces same results with plain PG and XC
>>>>>
>>>>> Also I changed the query in plain PG select_views test case to
>>>>> SELECT * FROM street ORDER BY name,cname,thepath::text;
>>>>> and obtained same results with plain PG and XC.
>>>>>
>>>>> I am not sure why the test case was passing earlier with the current
>>>>> possible expected outputs.
>>>>>
>>>>> Summarized design notes are attached with the mail for reference.
>>>>>
>>>>>  10) The modifications you are bringing to combocid_1.out are
>>>>>>> consistent with postgres, cool!
>>>>>>>
>>>>>>> No performance impact with this patch! Tested and approved. This is
>>>>>>> good.
>>>>>>> No regression impact with this patch.
>>>>>>>
>>>>>>> So, to conclude, I think it is a good piece of work, really cool
>>>>>>> stuff that I believe will be helpful for triggers and even other things.
>>>>>>> It just needs to be polished and simplified a bit. However basics
>>>>>>> are here, and performance is not impacted. Really it was worth spending
>>>>>>> time on that. The additional test cases also look to be sufficient, but I
>>>>>>> might be missing smth so feel free to add new tests if necessary.
>>>>>>> Thanks!
>>>>>>>
>>>>>>> --
>>>>>>> Michael Paquier
>>>>>>> http://michael.otacoo.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> Abbas
>>>>>> Architect
>>>>>> EnterpriseDB Corporation
>>>>>> The Enterprise PostgreSQL Company
>>>>>>
>>>>>> Phone: 92-334-5100153
>>>>>>
>>>>>> Website: www.enterprisedb.com
>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>>
>>>>>> This e-mail message (and any attachment) is intended for the use of
>>>>>> the individual or entity to whom it is addressed. This message
>>>>>> contains information from EnterpriseDB Corporation that may be
>>>>>> privileged, confidential, or exempt from disclosure under applicable
>>>>>> law. If you are not the intended recipient or authorized to receive
>>>>>> this for the intended recipient, any use, dissemination, distribution,
>>>>>> retention, archiving, or copying of this communication is strictly
>>>>>> prohibited. If you have received this e-mail in error, please notify
>>>>>> the sender immediately by reply e-mail and delete this message.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> --
>>>>> Abbas
>>>>> Architect
>>>>> EnterpriseDB Corporation
>>>>> The Enterprise PostgreSQL Company
>>>>>
>>>>> Phone: 92-334-5100153
>>>>>
>>>>> Website: www.enterprisedb.com
>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>
>>>>> This e-mail message (and any attachment) is intended for the use of
>>>>> the individual or entity to whom it is addressed. This message
>>>>> contains information from EnterpriseDB Corporation that may be
>>>>> privileged, confidential, or exempt from disclosure under applicable
>>>>> law. If you are not the intended recipient or authorized to receive
>>>>> this for the intended recipient, any use, dissemination, distribution,
>>>>> retention, archiving, or copying of this communication is strictly
>>>>> prohibited. If you have received this e-mail in error, please notify
>>>>> the sender immediately by reply e-mail and delete this message.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Paquier
>>>> http://michael.otacoo.com
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Abbas
>>> Architect
>>> EnterpriseDB Corporation
>>> The Enterprise PostgreSQL Company
>>>
>>> Phone: 92-334-5100153
>>>
>>> Website: www.enterprisedb.com
>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>
>>> This e-mail message (and any attachment) is intended for the use of
>>> the individual or entity to whom it is addressed. This message
>>> contains information from EnterpriseDB Corporation that may be
>>> privileged, confidential, or exempt from disclosure under applicable
>>> law. If you are not the intended recipient or authorized to receive
>>> this for the intended recipient, any use, dissemination, distribution,
>>> retention, archiving, or copying of this communication is strictly
>>> prohibited. If you have received this e-mail in error, please notify
>>> the sender immediately by reply e-mail and delete this message.
>>>
>>
>>
>>
>> --
>> Michael Paquier
>> http://michael.otacoo.com
>>
>
>
>
> --
> --
> Abbas
> Architect
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
> Phone: 92-334-5100153
>
> Website: www.enterprisedb.com
> EnterpriseDB Blog: http://blogs.enterprisedb.com/
> Follow us on Twitter: http://www.twitter.com/enterprisedb
>
> This e-mail message (and any attachment) is intended for the use of
> the individual or entity to whom it is addressed. This message
> contains information from EnterpriseDB Corporation that may be
> privileged, confidential, or exempt from disclosure under applicable
> law. If you are not the intended recipient or authorized to receive
> this for the intended recipient, any use, dissemination, distribution,
> retention, archiving, or copying of this communication is strictly
> prohibited. If you have received this e-mail in error, please notify
> the sender immediately by reply e-mail and delete this message.
>



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

Thanks Michael, I just reviewed the patch and found one small thing.

In the function transformInsertStmt where we set
SetSendCommandId(true);
I think it would be better to put this statement under an
if (IS_PGXC_COORDINATOR && !IsConnFromCoord())

Other than that I am OK with the changes.

Regards

On Mon, Jul 23, 2012 at 7:08 AM, Michael Paquier
<mic...@gm...>wrote:

> Hi,
>
> I spent some time this morning rewriting your patch.
> I reduced the number of functions and parameters to a minimum number and
> eliminated the useless message 'Y'.
> 'Y' definitely doesn't make sense as it has absolutely the same role as
> 'M'. In the former patch, the notion of notification is simply to send a
> message from Coordinator to Datanode, but a Datanode can also send a GXID,
> snapshot and timestamp using the same message types as the one used when a
> Coordinator sends data to a remote node. So we shouldn't lose this
> portability of the new messages. The only thing that changes for
> Coordinator->remoteNode and remoteCode->Coordinator communication protocol
> is the place where message is read. in the first case, message is received
> by remote node in postgres.c stuff. In the second case, message is received
> inside execRemote.c, so this distinction makes perfectly safe the fact of
> using the same message 'M', making 'Y' unnecessary.
> Also, it is really important to limit the number of used message types to
> reduce the footprint of XC code on PostgreSQL.
>
> There are no problems with regressions, and performance is not impacted. I
> also corrected some comment format and added some other comments at various
> places.
> In consequence, and to simplify the work of everybody, I am going to
> commit this largely simplified version of the patch.
>
> Thanks,
>
>
> On Sat, Jul 21, 2012 at 6:29 PM, Abbas Butt <abb...@en...>wrote:
>
>>
>>
>> On Fri, Jul 20, 2012 at 11:04 AM, Michael Paquier <
>> mic...@gm...> wrote:
>>
>>> Hi,
>>>
>>> Sorry for being a little bit picky here:
>>> 1) In GetCurrentSubTransactionId of xact.c, you can replace:
>>> if (IS_PGXC_DATANODE && isCommandIdReceived)
>>> {
>>>    foo
>>> }
>>> else
>>> {
>>>    if (IS_PGXC_COORDINATOR && !IsConnFromCoord())
>>>       re_foo
>>> }
>>> by:
>>> if (IS_PGXC_DATANODE && isCommandIdReceived)
>>> {
>>>    foo
>>> }
>>> else if (IS_PGXC_COORDINATOR && !IsConnFromCoord())
>>> {
>>>     re_foo
>>> }
>>>
>>
>> Done
>>
>>
>>> 2) I am not so much a fan of this 'Y' message as for now it just has a
>>> single usage, and M is doing exactly the same thing... But seen as a
>>> message that a remote node sends a notification to its backend, ok it makes
>>> some sense. In this case you should avoid to use a magic number like '1'.
>>> Please use a define like:
>>> #define DATANODE_NOTIFICATION_COMMAND_ID '1'
>>> A place like pgxc.h would make sense to define that.
>>> Then use this variable at the places where you need it
>>> (HandleDatanodeNotification of execRemote.c and ReportCommandIdChange of
>>> xact.c). It will bring more visibility to your code.
>>>
>>
>> Done
>>
>>
>>> 3) SetCmdIdSending and SetCmdIdReporting should be combined, they serve
>>> the same purpose. Their only difference is the node type where they are
>>> used. Let's make that generic. As a general name, SetCommandIdSending would
>>> be enough.
>>>
>>
>> I am not getting how to do that, consider the example of StartTransaction
>> function where we want to SetCmdIdReporting(false). Suppose we combine both
>> functions and have the new function like this
>>
>> void SetCmdIdSending(bool enb)
>> {
>>   if(IS_PGXC_COORDINATOR && !IsConnFromCoord())
>>     sendCommandId = enb;
>>   else if(IS_PGXC_DATANODE)
>>     sendCommandId = enb;
>> }
>>
>> and that we call this function instead of SetCmdIdReporting. It will work
>> OK for data node but when the same code executes for coordinator we will
>> set sendCommandId to false which was not required. Perhaps I did not get
>> your point.
>>
>>
>>> 4) GetCmdIdOfDatanode and GetCmdIdOfCoordinator should also be combined.
>>> They do exactly the same thing, the only difference is that one is launched
>>> on Datanode and the other on Coordinator. A general name like
>>> GetCommandIdReceived would be nicer.
>>>
>>
>> See my comment for point (3)
>>
>> 5) In portalcmds.c, PerformCursorOpen. You need to replace
>>> if (IS_PGXC_COORDINATOR)
>>>                GetCurrentCommandId(true);
>>> by:
>>> if (IS_PGXC_COORDINATOR && !IsConnFromCoord())
>>>                GetCurrentCommandId(true);
>>>
>>
>> Done.
>>
>>
>>> 6) For the regressions, I am still getting the diffs. Based on your
>>> test, I get this ordering for PG and XC:
>>> pgxc# select * from test_text order by 1;
>>>                  a
>>> ------------------------------------
>>>  Bancroft                      Ave
>>>  Bancroft                      Ave
>>>  Birch                         St
>>>  Birch                         St
>>>  Blacow                        Road
>>>  Bridgepointe                  Dr
>>>  Broadmore                     Ave
>>>  Broadway
>>>  B                             St
>>> (9 rows)
>>> If we are getting the same diffs we should change the output, it looks
>>> to be a side-effect of your fix for INSERT SELECT on parent-child,
>>>
>>
>> Done
>>
>>
>>>
>>> On Fri, Jul 20, 2012 at 2:15 AM, Abbas Butt <abb...@en...
>>> > wrote:
>>>
>>>> Attached please find the updated patch.
>>>>
>>>> On Thu, Jul 19, 2012 at 11:01 AM, Abbas Butt <
>>>> abb...@en...> wrote:
>>>>
>>>>> Thanks Michael for the review, Thanks Ashutosh for the comments,
>>>>> Michael I will accommodate your valuable feedback and will send
>>>>> revised patch.
>>>>> Ashutosh I will send the summarized design in the email with the
>>>>> revised patch.
>>>>> BTW enb is short for enable!
>>>>>
>>>>>
>>>>> On Thu, Jul 19, 2012 at 10:37 AM, Michael Paquier <
>>>>> mic...@gm...> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Finally I took some time to look at this code, it is important
>>>>>> support.
>>>>>> 1) The code is not realigned with current master (xc_misc.sql) and
>>>>>> contains whitespaces (2 in xc_misc.out, perhaps other files as well). So I
>>>>>> realigned it myself to test the code.
>>>>>>
>>>>>
>>>> The attached patch is aligned with the current master and I have
>>>> removed white spaces.
>>>>
>>>>
>>>>>  2) In GetCurrentCommandId xact.c, you need to set !IsConnFromCoord()
>>>>>> with (IS_PGXC_COORDINATOR) to avoid remote coordinators incrementing the
>>>>>> command ID. Remote Coordinators do not receive any command IDs from remote
>>>>>> nodes. Also here using an if/else if structure won't hurt and bring clarity
>>>>>> in the operations.
>>>>>>
>>>>>
>>>> Added the check and used if/else
>>>>
>>>>
>>>>>  3) In BeginTransactionBlock of xact.c, you need to add
>>>>>> !IsConnFromCoord() as a secondary condition to avoid remote Coordinator
>>>>>> problems.
>>>>>>
>>>>>
>>>> Done
>>>>
>>>>
>>>>> 4) By looking at the patch It is possible to reduce the number of
>>>>>> variables used for the control of Command ID. In the current version of
>>>>>> your patch, you are using 5 static variables:
>>>>>> static CommandId    cmdIdFromCoord;        /* Datanode will use
>>>>>> command id received from coordinator */
>>>>>> static bool        cmdIdRcvdAtDatanode;    /* Has the coordinator
>>>>>> sent command id to the data node? */
>>>>>> static bool        enbCmdIdChgReporting;    /* Should datanode report
>>>>>> command id changes to coordinator? */
>>>>>> static bool        enbCoordCmdIdSending;    /* Should coordinator
>>>>>> send command id to the data node? */
>>>>>> static CommandId    cmdIdFromDatanode;    /* Coordinator will receive
>>>>>> updated command id from datanode */
>>>>>> However, cmdIdRcvdAtDatanode, cmdIdFromCoord and enbCmdIdChgReporting
>>>>>> are used only at Datanode.
>>>>>> cmdIdFromDatanode and enbCoordCmdIdSending are only used at
>>>>>> Coordinator level.
>>>>>> You should combine enbCoordCmdIdSending and enbCmdIdChgReporting into
>>>>>> a single variable with a generic name, like let's say sendCommandId or
>>>>>> reportCommandId. Specifying in comments the role of this unique variable
>>>>>> for local Coordinator and remote nodes will help. Those 2 variables play
>>>>>> the same role which is to control if a
>>>>>> In the case of Coordinator, this variable is flagged to true when
>>>>>> transforming INSERT statements (transformInsertStmt) and when a transaction
>>>>>> block is begun (BeginTransactionBlock).
>>>>>> In the case of a Datanode, this variable is flagged to true only when
>>>>>> a command ID has been received from Coordinator.
>>>>>>
>>>>>>
>>>> Done, I used functions to retain code readability and inside the
>>>> functions I used the same variables as u suggested.
>>>>
>>>>
>>>>> Then, you should combine cmdIdFromCoord and cmdIdFromDatanode into a
>>>>>> single variable, like receivedCommandId. In this case, being at Coordinator
>>>>>> or at Datanode means that this command ID has been received from a remode
>>>>>> node. If you have other ideas for names please feel free!
>>>>>>
>>>>>
>>>> Done, again I used functions to retain code readability. I however had
>>>> to add checks inside the functions to make sure that the functions intended
>>>> for data node work only for data nodes and the ones intended for
>>>> coordinators work only for coordinators.
>>>>
>>>>
>>>>> Also changing the name cmdIdRcvdAtDatanode to isCommandIdReceived
>>>>>> might help...
>>>>>>
>>>>>
>>>> Done
>>>>
>>>>
>>>>> Just a question, what means the preffix enb? (just by curiosity) :)
>>>>>>
>>>>>> 5) In xact.c, at the end of CommitTransaction, PrepareTransaction,
>>>>>> CleanupTransaction, you will need to change the cleanup of the variables if
>>>>>> you take into account comment 4).
>>>>>>
>>>>>
>>>> Done
>>>>
>>>>
>>>>> 6) In BeginTransactionBlock, PrepareTransactionBlock,
>>>>>> EndTransactionBlock and UserAbortTransactionBlock of xact.c, you need to
>>>>>> set an additional !IsConnFromCoord() at this place, this will avoid remote
>>>>>> Coordinators trying to send CommandIds to inexistent nodes.
>>>>>> if(IS_PGXC_COORDINATOR)
>>>>>> +        SetCmdIdSending(false);
>>>>>>
>>>>>
>>>> Done
>>>>
>>>>
>>>>>
>>>>>> 7) You should combine the messages 'Y' and 'M'. The content and the
>>>>>> goals are the same. You can also eliminate the 2nd byte of 'Y' without
>>>>>> consequences I think.
>>>>>>
>>>>>
>>>> I did not combine these two. The intention of having them separate is
>>>> because 'Y' should not be tied to 'M', In future we might need data nodes
>>>> to notify coordinators of some thing else. And for the same reason I have
>>>> added a second byte in 'Y' so that we can have the same command notify
>>>> coordinators of some thing else.
>>>>
>>>>
>>>>> 8) Why didn't you put the reception of message 'M' in PostgresMain of
>>>>>> postgres.c at the same place as the reception of GXID, snapshot, timestamp,
>>>>>> etc.
>>>>>> Putting the reception of message at the end of SocketBackend makes
>>>>>> the code kind of inconsistent. If you keep it inside SocketBackend, you
>>>>>> should at least manage the message inside the switch, however I do not see
>>>>>> any particular reason why you receive this message in SocketBackend and not
>>>>>> in PostgresMain. So anything I should know?
>>>>>> You should also remove the flag IS_PGXC_DATANODE when receiving the
>>>>>> command ID. Remote Coordinator might need to be able to receive command IDs
>>>>>> as well, even if there is no direct usage now, but for stuff like triggers??
>>>>>>
>>>>>
>>>> Done, I added handling of 'M' in PostgresMain.
>>>>
>>>>
>>>>>  9) I found some diffs with the test select_views. It might be worth
>>>>>> to look at what is happening. It is perhaps an environment-related issue.
>>>>>> Btw, my regression diffs are attached.
>>>>>>
>>>>>
>>>> I was also getting these diffs but it was difficult for me to think
>>>> that the changes I did could cause a change in oder of rows. Here is what I
>>>> did to dig the issue deeper.
>>>>
>>>> create table test_text(a text);
>>>>
>>>> insert into test_text values('Bancroft                      Ave');
>>>> insert into test_text values('Bancroft                      Ave');
>>>> insert into test_text values('Birch                         St');
>>>> insert into test_text values('Birch                         St');
>>>> insert into test_text values('Blacow                        Road');
>>>> insert into test_text values('Bridgepointe                  Dr');
>>>> insert into test_text values('Broadmore                     Ave');
>>>> insert into test_text values('Broadway                          ');
>>>> insert into test_text values('B                             St');
>>>>
>>>> select * from test_text order by 1
>>>> produces same results with plain PG and XC
>>>>
>>>> Also I changed the query in plain PG select_views test case to
>>>> SELECT * FROM street ORDER BY name,cname,thepath::text;
>>>> and obtained same results with plain PG and XC.
>>>>
>>>> I am not sure why the test case was passing earlier with the current
>>>> possible expected outputs.
>>>>
>>>> Summarized design notes are attached with the mail for reference.
>>>>
>>>>  10) The modifications you are bringing to combocid_1.out are
>>>>>> consistent with postgres, cool!
>>>>>>
>>>>>> No performance impact with this patch! Tested and approved. This is
>>>>>> good.
>>>>>> No regression impact with this patch.
>>>>>>
>>>>>> So, to conclude, I think it is a good piece of work, really cool
>>>>>> stuff that I believe will be helpful for triggers and even other things.
>>>>>> It just needs to be polished and simplified a bit. However basics are
>>>>>> here, and performance is not impacted. Really it was worth spending time on
>>>>>> that. The additional test cases also look to be sufficient, but I might be
>>>>>> missing smth so feel free to add new tests if necessary.
>>>>>> Thanks!
>>>>>>
>>>>>> --
>>>>>> Michael Paquier
>>>>>> http://michael.otacoo.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> --
>>>>> Abbas
>>>>> Architect
>>>>> EnterpriseDB Corporation
>>>>> The Enterprise PostgreSQL Company
>>>>>
>>>>> Phone: 92-334-5100153
>>>>>
>>>>> Website: www.enterprisedb.com
>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>
>>>>> This e-mail message (and any attachment) is intended for the use of
>>>>> the individual or entity to whom it is addressed. This message
>>>>> contains information from EnterpriseDB Corporation that may be
>>>>> privileged, confidential, or exempt from disclosure under applicable
>>>>> law. If you are not the intended recipient or authorized to receive
>>>>> this for the intended recipient, any use, dissemination, distribution,
>>>>> retention, archiving, or copying of this communication is strictly
>>>>> prohibited. If you have received this e-mail in error, please notify
>>>>> the sender immediately by reply e-mail and delete this message.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Abbas
>>>> Architect
>>>> EnterpriseDB Corporation
>>>> The Enterprise PostgreSQL Company
>>>>
>>>> Phone: 92-334-5100153
>>>>
>>>> Website: www.enterprisedb.com
>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>
>>>> This e-mail message (and any attachment) is intended for the use of
>>>> the individual or entity to whom it is addressed. This message
>>>> contains information from EnterpriseDB Corporation that may be
>>>> privileged, confidential, or exempt from disclosure under applicable
>>>> law. If you are not the intended recipient or authorized to receive
>>>> this for the intended recipient, any use, dissemination, distribution,
>>>> retention, archiving, or copying of this communication is strictly
>>>> prohibited. If you have received this e-mail in error, please notify
>>>> the sender immediately by reply e-mail and delete this message.
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Paquier
>>> http://michael.otacoo.com
>>>
>>
>>
>>
>> --
>> --
>> Abbas
>> Architect
>> EnterpriseDB Corporation
>> The Enterprise PostgreSQL Company
>>
>> Phone: 92-334-5100153
>>
>> Website: www.enterprisedb.com
>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>
>> This e-mail message (and any attachment) is intended for the use of
>> the individual or entity to whom it is addressed. This message
>> contains information from EnterpriseDB Corporation that may be
>> privileged, confidential, or exempt from disclosure under applicable
>> law. If you are not the intended recipient or authorized to receive
>> this for the intended recipient, any use, dissemination, distribution,
>> retention, archiving, or copying of this communication is strictly
>> prohibited. If you have received this e-mail in error, please notify
>> the sender immediately by reply e-mail and delete this message.
>>
>
>
>
> --
> Michael Paquier
> http://michael.otacoo.com
>



-- 
--
Abbas
Architect
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: 92-334-5100153

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

Thanks.   I found the latter works for the master.
---
Koichi

On Mon, 23 Jul 2012 12:53:50 +0900
Michael Paquier <mic...@gm...> wrote:

> > 2. select application_name,upper(state),upper(sync_state) from
> > pg_stat_replication;
> >
> > This does not work.  pg_stat_replication has zero row.
> >
> Because this is datanode slave, we don't have GTM connection or
> > snapshot.  This might be a cause of the problem 2, or we might have
> > blocked to update pg_stat_replication system catalog.
> >
> pg_stat_replication has by definition one row per wal sender process:
> http://www.postgresql.org/docs/9.1/static/monitoring-stats.html#MONITORING-STATS-VIEWS-TABLE
> AFAIK, slave has no wal sender processes running, so it is normal to see
> nothing on the slave side, all the data is on the master side. The data is
> only available on master, Am I missing smth?
> You might be able to see rows in pg_stat_replication on a slave if you use
> cascading replication however, but this feature is only available in 9.2.
> Also, in the case of XC, you can use EXECUTE DIRECT to get the information
> of pg_stat_replication from remote nodes, Coordinators and Datanodes
> included.
> -- 
> Michael Paquier
> http://michael.otacoo.com

> 2. select application_name,upper(state),upper(sync_state) from
> pg_stat_replication;
>
> This does not work.  pg_stat_replication has zero row.
>
Because this is datanode slave, we don't have GTM connection or
> snapshot.  This might be a cause of the problem 2, or we might have
> blocked to update pg_stat_replication system catalog.
>
pg_stat_replication has by definition one row per wal sender process:
http://www.postgresql.org/docs/9.1/static/monitoring-stats.html#MONITORING-STATS-VIEWS-TABLE
AFAIK, slave has no wal sender processes running, so it is normal to see
nothing on the slave side, all the data is on the master side. The data is
only available on master, Am I missing smth?
You might be able to see rows in pg_stat_replication on a slave if you use
cascading replication however, but this feature is only available in 9.2.
Also, in the case of XC, you can use EXECUTE DIRECT to get the information
of pg_stat_replication from remote nodes, Coordinators and Datanodes
included.
-- 
Michael Paquier
http://michael.otacoo.com

Hi,

I had a chance to meet people from Linux-HA Japan an discussed how to
provide Pacemaker RA (resource agent) for coordinator/datanode.   I
found present PostgreSQL RA (for 9.1) uses the following queries to
the hot standby node.

1. select pg_is_in_recovery();

works fine.

2. select application_name,upper(state),upper(sync_state) from
pg_stat_replication;

This does not work.  pg_stat_replication has zero row.

3. select pg_last_xlog_replay_location(),pg_last_xlog_receive_location();

works fine.

4. select now();

works fine.

Because this is datanode slave, we don't have GTM connection or
snapshot.   This might be a cause of the problem 2, or we might have
blocked to update pg_stat_replication system catalog.

Any suggestions?
----------
Koichi Suzuki