postgres-xc-developers Mailing List for Postgres-XC

I have a problem.

Could you help me?


I have  three machines:


machine 1:  I have GTM

machine 2: I have PGXC  coordinator1 and node 1

machine 3 : I have PGXC corrdinator 2 and node 2


The Replication works successfull but when the machine 1 crashes  the
replication does not work.

How I can configure feature failover or something like it because machine 2
does not execute the querys and shows mistakes about pooling failed.



Regards





*I.S.C. Noe Adahi Gutiérrez Romero*
***Oracle® Certified Professional, Java® SE 6 Programmer*
*IBM® InfoShere® Guardium® Technical Professional v1*

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
}
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.
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.
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.
5) In portalcmds.c, PerformCursorOpen. You need to replace
if (IS_PGXC_COORDINATOR)
               GetCurrentCommandId(true);
by:
if (IS_PGXC_COORDINATOR && !IsConnFromCoord())
               GetCurrentCommandId(true);
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,

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