postgres-xc-developers Mailing List for Postgres-XC

On Sat, Jul 21, 2012 at 8:28 AM, Noe Gutierrez <noe...@gm...> wrote:

> 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.
>
Unlike OracleRAC, XC has no feature to fallback to a non-failed node if you
try to send a query to a failed node for a replicated table.
However, you can define a preferred node for a read operation of replicated
table. This will allow to redirect all the read operation to the node that
did not fail and avoid this error.
Write operations will still fail as long as the node 1 is not back online
however.

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

You will need slave nodes for Datanodes to do that, like postgres.
-- 
Michael Paquier
http://michael.otacoo.com

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.

GTM provides consistent transaction management to all the coordinators
and datanodes.   In this case, you should run another GTM on another
machine (could be machine 2 or machine 3) as standby.   GTM standby
backs up everything of the original GTM (master).    Also, please
configure machine 2 and machine 3 with gtm_proxy and connect all the
coordinator/datanode to their local gtm_proxy.

When GTM fails, you can promote the standby as the new master and
reconnect gtm_proxies to the new master.   They can be done by
gtm_ctl.

Good luck;
----------
Koichi Suzuki


2012/7/21 Noe Gutierrez <noe...@gm...>:
> 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
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>