Menu
▾
▴
postgres-xc-committers — Announces PG-XC repository commits
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(28) |
Jun
(12) |
Jul
(11) |
Aug
(12) |
Sep
(5) |
Oct
(19) |
Nov
(14) |
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(18) |
Feb
(30) |
Mar
(115) |
Apr
(89) |
May
(50) |
Jun
(44) |
Jul
(22) |
Aug
(13) |
Sep
(11) |
Oct
(30) |
Nov
(28) |
Dec
(39) |
| 2012 |
Jan
(38) |
Feb
(18) |
Mar
(43) |
Apr
(91) |
May
(108) |
Jun
(46) |
Jul
(37) |
Aug
(44) |
Sep
(33) |
Oct
(29) |
Nov
(36) |
Dec
(15) |
| 2013 |
Jan
(35) |
Feb
(611) |
Mar
(5) |
Apr
(55) |
May
(30) |
Jun
(28) |
Jul
(458) |
Aug
(34) |
Sep
(9) |
Oct
(39) |
Nov
(22) |
Dec
(32) |
| 2014 |
Jan
(16) |
Feb
(16) |
Mar
(42) |
Apr
(179) |
May
(7) |
Jun
(6) |
Jul
(9) |
Aug
|
Sep
(4) |
Oct
|
Nov
(3) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
|
2
(2) |
|
3
(1) |
4
|
5
(2) |
6
|
7
(9) |
8
(4) |
9
|
|
10
|
11
|
12
(4) |
13
(1) |
14
(1) |
15
(4) |
16
|
|
17
|
18
(2) |
19
(2) |
20
|
21
(5) |
22
|
23
|
|
24
|
25
|
26
(2) |
27
|
28
(4) |
29
(3) |
30
|
|
From: Michael P. <mic...@us...> - 2012-06-03 11:59:01
|
Project "Postgres-XC".
The branch, REL1_0_STABLE has been updated
via dc3d84756ca6d38dedc48e24813a9adcd9a6a241 (commit)
via 873d1c11ea25f24815861c2e474fc43500d561c8 (commit)
via 8e61ded616bdce65c43254b010f801f39b29ce3b (commit)
via 7651ec79879d36a68c9ab32a700ee034f7367701 (commit)
via 8620f6f18eee348075f7e3430c04d7784edf1b5c (commit)
via 3dfaea4727fb3d98e28f4cb9d707c33e2bdbfa7d (commit)
via 56901beb806bde7af419ad67f49086aaca4fc8df (commit)
via d72a3bd75813615898db27d4bbd2dca5cac9615a (commit)
via fea3ea1f23fb7f72aad28a55a09a60897a08dd3d (commit)
via 8db2e820c96a0ce33d3c15f476aa78bebce2c732 (commit)
via cc2469b0925812424efc8aa24234fc3090a5e85e (commit)
via 2791f2180d8e7c469fac2a4d88fc449689e4c970 (commit)
via 6c1bf45ea50a652d2b8efa778cabb63fdf422e70 (commit)
via 71e985a07a7ae9319c00629f319a4c30a9e32fd6 (commit)
via 1a93588ffcad3e4876c9610c0a35d79c7fcdeffe (commit)
via 4615d2ca28fe9dff6e5ebaebd6caf190a0c78ba5 (commit)
via 276bea211f08a3b0d6d5753b654322c8efb781d1 (commit)
via ae7c8b290f525504978c01d77366a753505d10d5 (commit)
via 9255d21d2fe5209c96b712f96c799fe594f00f4b (commit)
via 435a1437961d72c98a1dbd27c8a9fb75024730f9 (commit)
via 69c058ffc8949c6d86240b096196c4b6b64d87e0 (commit)
via 436af241c88a2f9b971dbe248e6ec6360438033c (commit)
via 2c1382d96c575a79a2ce014dda90fd1de78b3612 (commit)
via 2ca6bac892aa650154f591c730359a968bea726a (commit)
via f93e45d4071af89cf1b37c76fbd5976d11d77347 (commit)
via 1a4bc2db6cb80a6e52aed8f5a68b895231653d6c (commit)
via 153b1dbaa0b94143041ab1e0cf249a02380f0acf (commit)
via 1b48f6af315e9db89aaf43e8c8c9de903294fbdf (commit)
via 71ca53608de1763c0d82bf463580a30f634eba56 (commit)
via 05a86891232e1bd5e43d559f30bec2fc00131f37 (commit)
via e7c43ddc266172f409f5d5bb3e571cafe7d14fa2 (commit)
from 64c7d4d0aa32515db89069827e75a4997122b4bf (commit)
- Log -----------------------------------------------------------------
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=dc3d84756ca6d38dedc48e24813a9adcd9a6a241
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=873d1c11ea25f24815861c2e474fc43500d561c8
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=8e61ded616bdce65c43254b010f801f39b29ce3b
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=7651ec79879d36a68c9ab32a700ee034f7367701
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=8620f6f18eee348075f7e3430c04d7784edf1b5c
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=3dfaea4727fb3d98e28f4cb9d707c33e2bdbfa7d
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=56901beb806bde7af419ad67f49086aaca4fc8df
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=d72a3bd75813615898db27d4bbd2dca5cac9615a
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=fea3ea1f23fb7f72aad28a55a09a60897a08dd3d
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=8db2e820c96a0ce33d3c15f476aa78bebce2c732
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=cc2469b0925812424efc8aa24234fc3090a5e85e
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=2791f2180d8e7c469fac2a4d88fc449689e4c970
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=6c1bf45ea50a652d2b8efa778cabb63fdf422e70
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=71e985a07a7ae9319c00629f319a4c30a9e32fd6
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=1a93588ffcad3e4876c9610c0a35d79c7fcdeffe
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=4615d2ca28fe9dff6e5ebaebd6caf190a0c78ba5
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=276bea211f08a3b0d6d5753b654322c8efb781d1
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=ae7c8b290f525504978c01d77366a753505d10d5
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=9255d21d2fe5209c96b712f96c799fe594f00f4b
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=435a1437961d72c98a1dbd27c8a9fb75024730f9
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=69c058ffc8949c6d86240b096196c4b6b64d87e0
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=436af241c88a2f9b971dbe248e6ec6360438033c
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=2c1382d96c575a79a2ce014dda90fd1de78b3612
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=2ca6bac892aa650154f591c730359a968bea726a
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=f93e45d4071af89cf1b37c76fbd5976d11d77347
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=1a4bc2db6cb80a6e52aed8f5a68b895231653d6c
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=153b1dbaa0b94143041ab1e0cf249a02380f0acf
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=1b48f6af315e9db89aaf43e8c8c9de903294fbdf
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=71ca53608de1763c0d82bf463580a30f634eba56
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=05a86891232e1bd5e43d559f30bec2fc00131f37
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=e7c43ddc266172f409f5d5bb3e571cafe7d14fa2
commit dfee5379109a757e1bfaa9fe59830e6fb05f6688
Author: Michael Paquier <mi...@ot...>
Date: Sun Jun 3 05:29:06 2012 +0900
Block node registration for slave nodes and perform register at a stable state
Performing node registration on GTM just after postmaster start is dangerous
because the master/slave status of the node is unknown. So node
registration is done once node has reached a stable state, meaning that
Xlog process has confirmed to postmaster that recovery has been completed.
Registration is also blocked for slave nodes. A standby node is created
from a hot backup of its master so master and its slaves will share the
same node name. Two nodes are not authorized to register to GTM with the
same node name to avoid identification confusion in the cluster, so it
looks normal to let the master and the master only identify itself.
A a direct consequence, unregistration too is done only for master node.
Synchronous and asynchronous node replication works correctly with this fix,
as well as node promotion (Ex: "pg_ctl promote -D $DATA").
M src/backend/postmaster/postmaster.c
-----------------------------------------------------------------------
Summary of changes:
configure | 3 +-
contrib/citext/citext--unpackaged--1.0.sql | 97 ++-
contrib/pg_standby/pg_standby.c | 4 +-
contrib/pg_stat_statements/pg_stat_statements.c | 22 +-
contrib/pgcrypto/crypt-des.c | 3 +-
contrib/sepgsql/expected/label.out | 2 +-
doc/bug.template | 2 +-
doc/src/sgml/release-8.3.sgml | 229 ++++
doc/src/sgml/release-8.4.sgml | 285 ++++
doc/src/sgml/release-9.0.sgml | 320 +++++
doc/src/sgml/release-9.1.sgml | 506 +++++++-
src/backend/access/gist/gist.c | 123 ++-
src/backend/access/heap/heapam.c | 7 +
src/backend/access/index/genam.c | 11 +-
src/backend/access/nbtree/README | 8 +-
src/backend/access/nbtree/nbtpage.c | 32 +-
src/backend/access/nbtree/nbtxlog.c | 6 +-
src/backend/access/transam/xact.c | 19 +-
src/backend/catalog/heap.c | 32 +-
src/backend/catalog/objectaddress.c | 4 +
src/backend/commands/tablecmds.c | 4 +
src/backend/commands/tablespace.c | 15 +-
src/backend/po/de.po | 1415 ++++++++++----------
src/backend/po/es.po | 1378 ++++++++++----------
src/backend/po/fr.po | 1644 ++++++++++++-----------
src/backend/po/ru.po | 2 -
src/backend/po/zh_CN.po | 2 -
src/backend/po/zh_TW.po | 1 -
src/backend/port/win32_sema.c | 20 +-
src/backend/postmaster/postmaster.c | 12 +-
src/backend/tsearch/to_tsany.c | 7 +-
src/backend/utils/adt/date.c | 5 +-
src/backend/utils/adt/datetime.c | 6 +-
src/backend/utils/adt/name.c | 10 +-
src/backend/utils/adt/varchar.c | 14 +-
src/backend/utils/adt/varlena.c | 12 +-
src/backend/utils/fmgr/fmgr.c | 15 +-
src/bin/initdb/po/de.po | 6 +-
src/bin/initdb/po/es.po | 17 -
src/bin/initdb/po/fr.po | 2 -
src/bin/initdb/po/ru.po | 2 -
src/bin/initdb/po/zh_CN.po | 4 +-
src/bin/pg_basebackup/po/cs.po | 1 -
src/bin/pg_basebackup/po/de.po | 82 +-
src/bin/pg_basebackup/po/es.po | 80 +-
src/bin/pg_basebackup/po/fr.po | 92 +-
src/bin/pg_config/po/de.po | 2 -
src/bin/pg_config/po/es.po | 2 -
src/bin/pg_config/po/fr.po | 2 -
src/bin/pg_config/po/ru.po | 2 -
src/bin/pg_controldata/po/cs.po | 2 -
src/bin/pg_controldata/po/de.po | 2 -
src/bin/pg_controldata/po/es.po | 2 -
src/bin/pg_controldata/po/fr.po | 2 -
src/bin/pg_controldata/po/ru.po | 2 -
src/bin/pg_ctl/po/de.po | 2 -
src/bin/pg_ctl/po/es.po | 13 -
src/bin/pg_ctl/po/fr.po | 2 -
src/bin/pg_ctl/po/ru.po | 2 -
src/bin/pg_dump/common.c | 18 +-
src/bin/pg_dump/pg_dump.c | 39 +-
src/bin/pg_dump/pg_dump.h | 1 +
src/bin/pg_dump/po/cs.po | 2 -
src/bin/pg_dump/po/de.po | 11 +-
src/bin/pg_dump/po/es.po | 2 -
src/bin/pg_dump/po/fr.po | 4 +-
src/bin/pg_dump/po/ru.po | 2 -
src/bin/pg_dump/po/sv.po | 2 -
src/bin/pg_resetxlog/po/cs.po | 2 -
src/bin/pg_resetxlog/po/de.po | 2 -
src/bin/pg_resetxlog/po/es.po | 2 -
src/bin/pg_resetxlog/po/fr.po | 2 -
src/bin/pg_resetxlog/po/ru.po | 2 -
src/bin/psql/describe.c | 7 +
src/bin/psql/po/de.po | 169 ++--
src/bin/psql/po/es.po | 157 ++-
src/bin/psql/po/fr.po | 207 ++--
src/bin/psql/po/ru.po | 2 -
src/bin/psql/po/zh_TW.po | 1 -
src/bin/scripts/po/cs.po | 2 -
src/bin/scripts/po/de.po | 19 +-
src/bin/scripts/po/es.po | 8 -
src/bin/scripts/po/fr.po | 2 -
src/bin/scripts/po/ru.po | 2 -
src/include/catalog/heap.h | 2 +
src/include/pg_config.h.win32 | 6 +-
src/include/utils/timestamp.h | 10 +
src/interfaces/ecpg/ecpglib/po/de.po | 2 -
src/interfaces/ecpg/ecpglib/po/es.po | 2 -
src/interfaces/ecpg/ecpglib/po/fr.po | 2 -
src/interfaces/ecpg/preproc/po/de.po | 2 -
src/interfaces/ecpg/preproc/po/es.po | 14 -
src/interfaces/ecpg/preproc/po/fr.po | 2 -
src/interfaces/libpq/libpq.rc.in | 8 +-
src/interfaces/libpq/po/cs.po | 2 -
src/interfaces/libpq/po/de.po | 133 +-
src/interfaces/libpq/po/es.po | 119 +-
src/interfaces/libpq/po/fr.po | 167 ++--
src/interfaces/libpq/po/it.po | 1 -
src/interfaces/libpq/po/ru.po | 2 -
src/interfaces/libpq/po/sv.po | 2 -
src/interfaces/libpq/po/zh_CN.po | 2 -
src/interfaces/libpq/po/zh_TW.po | 1 -
src/pl/plperl/po/cs.po | 1 -
src/pl/plperl/po/de.po | 2 -
src/pl/plperl/po/es.po | 7 -
src/pl/plperl/po/fr.po | 2 -
src/pl/plpgsql/src/pl_exec.c | 1 +
src/pl/plpgsql/src/po/es.po | 2 -
src/pl/plpgsql/src/po/fr.po | 2 -
src/pl/plpython/po/de.po | 167 ++-
src/pl/plpython/po/es.po | 190 ++--
src/pl/plpython/po/fr.po | 176 ++--
src/pl/tcl/po/de.po | 2 -
src/pl/tcl/po/es.po | 2 -
src/pl/tcl/po/fr.po | 2 -
src/port/win32ver.rc | 4 +-
src/test/regress/input/security_label.source | 1 +
src/test/regress/output/security_label.source | 2 +
src/timezone/data/africa | 36 +-
src/timezone/data/antarctica | 21 +-
src/timezone/data/asia | 72 +-
src/timezone/data/australasia | 28 +-
src/timezone/data/europe | 14 +-
src/timezone/data/leapseconds | 42 +-
src/timezone/data/northamerica | 135 ++-
src/timezone/data/southamerica | 53 +-
src/timezone/data/zone.tab | 5 +-
128 files changed, 5253 insertions(+), 3462 deletions(-)
hooks/post-receive
--
Postgres-XC
|
