You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(17) |
Jun
(3) |
Jul
|
Aug
|
Sep
(8) |
Oct
(18) |
Nov
(51) |
Dec
(74) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
(47) |
Feb
(44) |
Mar
(44) |
Apr
(102) |
May
(35) |
Jun
(25) |
Jul
(56) |
Aug
(69) |
Sep
(32) |
Oct
(37) |
Nov
(31) |
Dec
(16) |
2012 |
Jan
(34) |
Feb
(127) |
Mar
(218) |
Apr
(252) |
May
(80) |
Jun
(137) |
Jul
(205) |
Aug
(159) |
Sep
(35) |
Oct
(50) |
Nov
(82) |
Dec
(52) |
2013 |
Jan
(107) |
Feb
(159) |
Mar
(118) |
Apr
(163) |
May
(151) |
Jun
(89) |
Jul
(106) |
Aug
(177) |
Sep
(49) |
Oct
(63) |
Nov
(46) |
Dec
(7) |
2014 |
Jan
(65) |
Feb
(128) |
Mar
(40) |
Apr
(11) |
May
(4) |
Jun
(8) |
Jul
(16) |
Aug
(11) |
Sep
(4) |
Oct
(1) |
Nov
(5) |
Dec
(16) |
2015 |
Jan
(5) |
Feb
|
Mar
(2) |
Apr
(5) |
May
(4) |
Jun
(12) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
|
1
(19) |
2
(15) |
3
|
4
(1) |
5
(17) |
6
(26) |
7
(18) |
8
(25) |
9
(7) |
10
(2) |
11
|
12
(6) |
13
(1) |
14
(5) |
15
(1) |
16
|
17
|
18
|
19
|
20
(3) |
21
(1) |
22
(14) |
23
(10) |
24
|
25
|
26
(11) |
27
(19) |
28
(1) |
29
(9) |
30
(7) |
31
|
From: Koichi S. <koi...@gm...> - 2012-03-20 12:09:36
|
Another info: Transactions involved by the failed datanode will fail. When a coordinator detects failure of a datanode, it aborts live transactions the failed datanode is involved. When multiple datanodes are involved, coordinator will abort the transaction at all such datanodes. After then, transactions involved by the failed node will fail too. When the crashed datanode is recovered and rejoins the cluster, transactions running at the time of crash may remain "prepared", "committed" or "aborted". We need to cleanup them and synchronize with other cluster node status. I'm writing a tool "pgxc_clean" to take care of this (so far, we have to do some tricky step to clean this up) and I do hope this is in V1.0. I'm afraid this explanation is not simple. Best Regards; ---------- Koichi Suzuki 2012年3月20日19:41 Ashutosh Bapat <ash...@en...>: > Hi Kris, > About choosing node to read in replicated tables - Every coordinator has a > list of preferred nodes. If a table is replicated on a preferred node, that > node is chosen to read. > > > On Tue, Mar 20, 2012 at 3:49 PM, Krzysztof Nowicki > <krz...@gm...> wrote: >> >> Hi all, >> >> I can't find information about some aspects of postgres-xc, maybe >> someone could quick answer to the following questions: >> >> Where GTM stores data ? >> >> Which algorithm is used to choose node for READ in replicated tables ? >> >> When some of data node crash and then after recover if data will >> automatically be synchronize ? >> >> What happened with transaction when during processing one of the node >> in the cluster crash ( rollback or commited) ? What happened with next >> transactions ? >> >> BR, >> >> Kris Nowicki >> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> 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 > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > |
From: Ashutosh B. <ash...@en...> - 2012-03-20 10:41:46
|
Hi Kris, About choosing node to read in replicated tables - Every coordinator has a list of preferred nodes. If a table is replicated on a preferred node, that node is chosen to read. On Tue, Mar 20, 2012 at 3:49 PM, Krzysztof Nowicki < krz...@gm...> wrote: > Hi all, > > I can't find information about some aspects of postgres-xc, maybe > someone could quick answer to the following questions: > > Where GTM stores data ? > > Which algorithm is used to choose node for READ in replicated tables ? > > When some of data node crash and then after recover if data will > automatically be synchronize ? > > What happened with transaction when during processing one of the node > in the cluster crash ( rollback or commited) ? What happened with next > transactions ? > > BR, > > Kris Nowicki > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > 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 |
From: Krzysztof N. <krz...@gm...> - 2012-03-20 10:19:12
|
Hi all, I can't find information about some aspects of postgres-xc, maybe someone could quick answer to the following questions: Where GTM stores data ? Which algorithm is used to choose node for READ in replicated tables ? When some of data node crash and then after recover if data will automatically be synchronize ? What happened with transaction when during processing one of the node in the cluster crash ( rollback or commited) ? What happened with next transactions ? BR, Kris Nowicki |