Menu
▾
▴
postgres-xc-general — General info and messages
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
(19) |
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(12) |
Feb
(1) |
Mar
(4) |
Apr
(4) |
May
(32) |
Jun
(12) |
Jul
(11) |
Aug
(1) |
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(10) |
| 2012 |
Jan
(11) |
Feb
(1) |
Mar
(3) |
Apr
(25) |
May
(53) |
Jun
(38) |
Jul
(103) |
Aug
(54) |
Sep
(31) |
Oct
(66) |
Nov
(77) |
Dec
(20) |
| 2013 |
Jan
(91) |
Feb
(86) |
Mar
(103) |
Apr
(107) |
May
(25) |
Jun
(37) |
Jul
(17) |
Aug
(59) |
Sep
(38) |
Oct
(78) |
Nov
(29) |
Dec
(15) |
| 2014 |
Jan
(23) |
Feb
(82) |
Mar
(118) |
Apr
(101) |
May
(103) |
Jun
(45) |
Jul
(6) |
Aug
(10) |
Sep
|
Oct
(32) |
Nov
|
Dec
(9) |
| 2015 |
Jan
(3) |
Feb
(5) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(9) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
|
2
|
3
|
4
|
|
5
|
6
|
7
|
8
|
9
(1) |
10
(3) |
11
|
|
12
|
13
(2) |
14
|
15
|
16
|
17
|
18
|
|
19
|
20
|
21
|
22
(1) |
23
|
24
|
25
|
|
26
|
27
|
28
(2) |
29
|
30
|
31
|
|
|
From: Silva, R. <rs...@ja...> - 2015-07-28 15:11:19
|
Fellow XL users & developers, Is there documentation out there on the internets regarding datanode count and performance for an XL environment? We currently have 10 datanodes and now contemplating the performance impact if we were to add 5 more. thank you... R!chard Silva ETL Architect o 972 443 7052 e rs...@ja...<applewebdata://DB38DD67-D9E1-4CF8-8E0C-08B3C400B24A/rs...@ja...> | www.javelin.mg<applewebdata://C6724941-5434-4FFF-A530-0F83A527BB10/www.javelin.mg> Access Manager: This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is prohibited. If you have received this e-mail in error, please immediately notify us by calling the Help Desk at (855) 237-8324. |
|
From: 鈴木 幸市 <ko...@in...> - 2015-07-28 01:31:58
|
Yes, this has already been reported and fix is available at github repo, https://github.com/postgres-x2/postgres-x2 Please try REL1_2_STABLE or REL1_1_STABLE branch. They are candidate for the next minor release. Regards; --- Koichi Suzuki NTT DATA Intellilink Corp. ko...@in... > 2015/07/20 17:43、Artur Graniszewski <aa...@bo...> のメール： > > Hi > > I found a strange issue when creating the database in Postgres XC: > > postgres=# create database bench2; > WARNING: unexpected EOF on datanode connection > WARNING: unexpected EOF on datanode connection > ERROR: sorry, too many clients already > > This happens randomly so I can't easily reproduce this issue but sometimes > after that error, I'm unable to access one of the datanodes because of "too > many clients already" message (even though I'm the only user using these > instances). This may be somehow connected to > > > This issue appears on the following version of XC: > psql (PGXC 1.1, based on PG 9.2.4) > > I use two datanodes&coordinators on separate machines and additional one > with GTM only > > Cheers, > Artur > > ------------------------------------------------------------------------------ > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > |
|
From: Artur G. <aa...@bo...> - 2015-07-22 20:38:27
|
Hi I found a strange issue when creating the database in Postgres XC: postgres=# create database bench2; WARNING: unexpected EOF on datanode connection WARNING: unexpected EOF on datanode connection ERROR: sorry, too many clients already This happens randomly so I can't easily reproduce this issue but sometimes after that error, I'm unable to access one of the datanodes because of "too many clients already" message (even though I'm the only user using these instances). This may be somehow connected to This issue appears on the following version of XC: psql (PGXC 1.1, based on PG 9.2.4) I use two datanodes&coordinators on separate machines and additional one with GTM only Cheers, Artur |
|
From: Koichi S. <koi...@gm...> - 2015-07-13 08:01:53
|
To be honest, yes and unfortunately, it is common to XL. Now XC has new developer team and is planning to make next release this August. This fix is included in the plan too. This fix can go to XL too. Regards; --- Koichi Suzuki https://www.linkedin.com/in/koichidbms 2015-07-13 16:28 GMT+09:00 Artur Graniszewski <aa...@bo...>: > Hi, > > does it mean that CREATE TABLE command may fail the same way? Is there any > possibility to reduce the risk of such situation by for example setting > preferred or primary node in Postgre XC configuration? (ALTER NODE > command). > > Also, how often are the new versions (with bugfixes) of XC released? I > know that fixing such bug could take a while, but I wonder if this fix > won't be hindered by a release plan too.. > > On Fri, 10 Jul 2015 13:13:30 +0900, Koichi Suzuki <koi...@gm...> > wrote: > > In PGXC, DDL operation is not serialized, I mean, the order of the node > > where each peace of DDL executed is not defined. This may cause some > race > > conditions and could cause local errors, resulting in inconsistent > status. > > > > Recetly, I found CREATE TABLE in parallel schedule of regression test > cause > > similar problems. I think this is common to XC and XL. > > > > There are a couple of ways to fix this: > > > > 1. Use coordinator primary node to go first, as done in replicated > tables, > > 2. Serialize DDL execution, possibly by using advisory lock internally. > > > > Anyway, this is a bug and we need a fix. Solution 1 is bit more > > complicated than 2. > > > > Best; > > > > --- > > Koichi Suzuki > > https://www.linkedin.com/in/koichidbms > > > > > > 2015-07-09 23:22 GMT+09:00 Artur Graniszewski <aa...@bo...>: > > > >> Hi, > >> > >> I just finished the multi-master configuration of Postgres XC on my > test > >> environment (three virtual machines): > >> > >> * VM1 - with GTM only > >> * VM2, VM2 - two masters with one data-node and one coordinator on each > >> machine > >> > >> I tried to create some databases on each master to check if everything > >> works ok, but I found a strange issue with one database that had been > >> created only on one of the masters (while other databases I created and > >> deleted afterwards were ok): > >> > >> postgres=# \l > >> List of databases > >> Name | Owner | Encoding | Collate | Ctype | Access > >> privileges > >> > >> > > -----------+----------+----------+-------------+-------------+----------------------- > >> postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > >> template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > >> =c/postgres + > >> | | | | | > >> postgres=CTc/postgres > >> template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > >> =c/postgres + > >> | | | | | > >> postgres=CTc/postgres > >> test2 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > >> whatnot | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > >> > >> vs > >> > >> postgres=# \l > >> List of databases > >> Name | Owner | Encoding | Collate | Ctype | Access > >> privileges > >> > >> > > -----------+----------+----------+-------------+-------------+----------------------- > >> postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > >> template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > >> =c/postgres + > >> | | | | | > >> postgres=CTc/postgres > >> template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > >> =c/postgres + > >> | | | | | > >> postgres=CTc/postgres > >> whatnot | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > >> > >> Unfortunately, when I try to perform any DDL command on a server that > >> sees > >> "test2" database I receive the following errors: > >> > >> postgres=# drop database test2; > >> ERROR: database "test2" does not exist > >> postgres=# create database test2; > >> ERROR: database "test2" already exists > >> > >> Also, when I try to remove another database called "whatnot", drop > >> operation never finishes. It looks like a transaction that hangs some > DDL > >> operations: > >> > >> postgres=# select * from pgxc_prepared_xacts; > >> pgxc_prepared_xact > >> -------------------- > >> T74589 > >> (1 row) > >> > >> postgres=# select * from pg_prepared_xacts; > >> transaction | gid | prepared | owner | > >> database > >> > >> > > -------------+--------+-------------------------------+----------+---------- > >> 73716 | T73716 | 2015-07-09 12:58:25.823385+02 | postgres | > >> postgres > >> (1 row) > >> > >> postgres=# > >> > >> When I try to rollback the transaction, Postgres says that given GID > does > >> not exist. > >> > >> Is it a bug in Postgres XC? Is there a way to synchronize the masters? > >> (eg > >> delete "test2" on one master and "whatnot" on both of them). Please > keep > >> in > >> mind that I created/dropped more databases without any issues, so I'm > >> unsure what went wrong in case of these two specific databases. > >> > >> Cheers, > >> > >> Artur > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > ------------------------------------------------------------------------------ > >> Don't Limit Your Business. Reach for the Cloud. > >> GigeNET's Cloud Solutions provide you with the tools and support that > >> you need to offload your IT needs and focus on growing your business. > >> Configured For All Businesses. Start Your Cloud Today. > >> https://www.gigenetcloud.com/ > >> _______________________________________________ > >> Postgres-xc-general mailing list > >> Pos...@li... > >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > >> > >> > |
|
From: Artur G. <aa...@bo...> - 2015-07-13 07:28:31
|
Hi, does it mean that CREATE TABLE command may fail the same way? Is there any possibility to reduce the risk of such situation by for example setting preferred or primary node in Postgre XC configuration? (ALTER NODE command). Also, how often are the new versions (with bugfixes) of XC released? I know that fixing such bug could take a while, but I wonder if this fix won't be hindered by a release plan too.. On Fri, 10 Jul 2015 13:13:30 +0900, Koichi Suzuki <koi...@gm...> wrote: > In PGXC, DDL operation is not serialized, I mean, the order of the node > where each peace of DDL executed is not defined. This may cause some race > conditions and could cause local errors, resulting in inconsistent status. > > Recetly, I found CREATE TABLE in parallel schedule of regression test cause > similar problems. I think this is common to XC and XL. > > There are a couple of ways to fix this: > > 1. Use coordinator primary node to go first, as done in replicated tables, > 2. Serialize DDL execution, possibly by using advisory lock internally. > > Anyway, this is a bug and we need a fix. Solution 1 is bit more > complicated than 2. > > Best; > > --- > Koichi Suzuki > https://www.linkedin.com/in/koichidbms > > > 2015-07-09 23:22 GMT+09:00 Artur Graniszewski <aa...@bo...>: > >> Hi, >> >> I just finished the multi-master configuration of Postgres XC on my test >> environment (three virtual machines): >> >> * VM1 - with GTM only >> * VM2, VM2 - two masters with one data-node and one coordinator on each >> machine >> >> I tried to create some databases on each master to check if everything >> works ok, but I found a strange issue with one database that had been >> created only on one of the masters (while other databases I created and >> deleted afterwards were ok): >> >> postgres=# \l >> List of databases >> Name | Owner | Encoding | Collate | Ctype | Access >> privileges >> >> -----------+----------+----------+-------------+-------------+----------------------- >> postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> =c/postgres + >> | | | | | >> postgres=CTc/postgres >> template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> =c/postgres + >> | | | | | >> postgres=CTc/postgres >> test2 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> whatnot | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> >> vs >> >> postgres=# \l >> List of databases >> Name | Owner | Encoding | Collate | Ctype | Access >> privileges >> >> -----------+----------+----------+-------------+-------------+----------------------- >> postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> =c/postgres + >> | | | | | >> postgres=CTc/postgres >> template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> =c/postgres + >> | | | | | >> postgres=CTc/postgres >> whatnot | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> >> Unfortunately, when I try to perform any DDL command on a server that >> sees >> "test2" database I receive the following errors: >> >> postgres=# drop database test2; >> ERROR: database "test2" does not exist >> postgres=# create database test2; >> ERROR: database "test2" already exists >> >> Also, when I try to remove another database called "whatnot", drop >> operation never finishes. It looks like a transaction that hangs some DDL >> operations: >> >> postgres=# select * from pgxc_prepared_xacts; >> pgxc_prepared_xact >> -------------------- >> T74589 >> (1 row) >> >> postgres=# select * from pg_prepared_xacts; >> transaction | gid | prepared | owner | >> database >> >> -------------+--------+-------------------------------+----------+---------- >> 73716 | T73716 | 2015-07-09 12:58:25.823385+02 | postgres | >> postgres >> (1 row) >> >> postgres=# >> >> When I try to rollback the transaction, Postgres says that given GID does >> not exist. >> >> Is it a bug in Postgres XC? Is there a way to synchronize the masters? >> (eg >> delete "test2" on one master and "whatnot" on both of them). Please keep >> in >> mind that I created/dropped more databases without any issues, so I'm >> unsure what went wrong in case of these two specific databases. >> >> Cheers, >> >> Artur >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Don't Limit Your Business. Reach for the Cloud. >> GigeNET's Cloud Solutions provide you with the tools and support that >> you need to offload your IT needs and focus on growing your business. >> Configured For All Businesses. Start Your Cloud Today. >> https://www.gigenetcloud.com/ >> _______________________________________________ >> Postgres-xc-general mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >> >> |
|
From: Koichi S. <koi...@gm...> - 2015-07-10 06:03:49
|
Yes, I agree. I began to write a code for this. In creating/dropping nodes, transaction level lock is used. Because some DDL don’t run inside the session block, I think we should use session level, although we need some error handling when the transaction aborts. Thank you; --- Koichi Suzuki https://www.linkedin.com/in/koichidbms 2015-07-10 14:11 GMT+09:00 Ashutosh Bapat <ash...@en...>: > I vaguely remember, Abbas had used advisory lock machinary for creating > and dropping nodes. May be we have to use the same mechanism for all DDLs. > > On Fri, Jul 10, 2015 at 9:43 AM, Koichi Suzuki <koi...@gm...> > wrote: > >> In PGXC, DDL operation is not serialized, I mean, the order of the node >> where each peace of DDL executed is not defined. This may cause some race >> conditions and could cause local errors, resulting in inconsistent status. >> >> Recetly, I found CREATE TABLE in parallel schedule of regression test >> cause similar problems. I think this is common to XC and XL. >> >> There are a couple of ways to fix this: >> >> 1. Use coordinator primary node to go first, as done in replicated tables, >> 2. Serialize DDL execution, possibly by using advisory lock internally. >> >> Anyway, this is a bug and we need a fix. Solution 1 is bit more >> complicated than 2. >> >> Best; >> >> --- >> Koichi Suzuki >> https://www.linkedin.com/in/koichidbms >> >> >> 2015-07-09 23:22 GMT+09:00 Artur Graniszewski <aa...@bo...>: >> >>> Hi, >>> >>> I just finished the multi-master configuration of Postgres XC on my test >>> environment (three virtual machines): >>> >>> * VM1 - with GTM only >>> * VM2, VM2 - two masters with one data-node and one coordinator on each >>> machine >>> >>> I tried to create some databases on each master to check if everything >>> works ok, but I found a strange issue with one database that had been >>> created only on one of the masters (while other databases I created and >>> deleted afterwards were ok): >>> >>> postgres=# \l >>> List of databases >>> Name | Owner | Encoding | Collate | Ctype | Access >>> privileges >>> >>> -----------+----------+----------+-------------+-------------+----------------------- >>> postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >>> template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >>> =c/postgres + >>> | | | | | >>> postgres=CTc/postgres >>> template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >>> =c/postgres + >>> | | | | | >>> postgres=CTc/postgres >>> test2 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >>> whatnot | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >>> >>> vs >>> >>> postgres=# \l >>> List of databases >>> Name | Owner | Encoding | Collate | Ctype | Access >>> privileges >>> >>> -----------+----------+----------+-------------+-------------+----------------------- >>> postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >>> template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >>> =c/postgres + >>> | | | | | >>> postgres=CTc/postgres >>> template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >>> =c/postgres + >>> | | | | | >>> postgres=CTc/postgres >>> whatnot | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >>> >>> Unfortunately, when I try to perform any DDL command on a server that >>> sees "test2" database I receive the following errors: >>> >>> postgres=# drop database test2; >>> ERROR: database "test2" does not exist >>> postgres=# create database test2; >>> ERROR: database "test2" already exists >>> >>> Also, when I try to remove another database called "whatnot", drop >>> operation never finishes. It looks like a transaction that hangs some DDL >>> operations: >>> >>> postgres=# select * from pgxc_prepared_xacts; >>> pgxc_prepared_xact >>> -------------------- >>> T74589 >>> (1 row) >>> >>> postgres=# select * from pg_prepared_xacts; >>> transaction | gid | prepared | owner | >>> database >>> >>> -------------+--------+-------------------------------+----------+---------- >>> 73716 | T73716 | 2015-07-09 12:58:25.823385+02 | postgres | >>> postgres >>> (1 row) >>> >>> postgres=# >>> >>> When I try to rollback the transaction, Postgres says that given GID >>> does not exist. >>> >>> Is it a bug in Postgres XC? Is there a way to synchronize the masters? >>> (eg delete "test2" on one master and "whatnot" on both of them). Please >>> keep in mind that I created/dropped more databases without any issues, so >>> I'm unsure what went wrong in case of these two specific databases. >>> >>> Cheers, >>> >>> Artur >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Don't Limit Your Business. Reach for the Cloud. >>> GigeNET's Cloud Solutions provide you with the tools and support that >>> you need to offload your IT needs and focus on growing your business. >>> Configured For All Businesses. Start Your Cloud Today. >>> https://www.gigenetcloud.com/ >>> _______________________________________________ >>> Postgres-xc-general mailing list >>> Pos...@li... >>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Don't Limit Your Business. Reach for the Cloud. >> GigeNET's Cloud Solutions provide you with the tools and support that >> you need to offload your IT needs and focus on growing your business. >> Configured For All Businesses. Start Your Cloud Today. >> https://www.gigenetcloud.com/ >> _______________________________________________ >> Postgres-xc-general mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >> >> > > > -- > Best Wishes, > Ashutosh Bapat > EnterpriseDB Corporation > The Postgres Database Company > |
|
From: Ashutosh B. <ash...@en...> - 2015-07-10 05:42:17
|
I vaguely remember, Abbas had used advisory lock machinary for creating and dropping nodes. May be we have to use the same mechanism for all DDLs. On Fri, Jul 10, 2015 at 9:43 AM, Koichi Suzuki <koi...@gm...> wrote: > In PGXC, DDL operation is not serialized, I mean, the order of the node > where each peace of DDL executed is not defined. This may cause some race > conditions and could cause local errors, resulting in inconsistent status. > > Recetly, I found CREATE TABLE in parallel schedule of regression test > cause similar problems. I think this is common to XC and XL. > > There are a couple of ways to fix this: > > 1. Use coordinator primary node to go first, as done in replicated tables, > 2. Serialize DDL execution, possibly by using advisory lock internally. > > Anyway, this is a bug and we need a fix. Solution 1 is bit more > complicated than 2. > > Best; > > --- > Koichi Suzuki > https://www.linkedin.com/in/koichidbms > > > 2015-07-09 23:22 GMT+09:00 Artur Graniszewski <aa...@bo...>: > >> Hi, >> >> I just finished the multi-master configuration of Postgres XC on my test >> environment (three virtual machines): >> >> * VM1 - with GTM only >> * VM2, VM2 - two masters with one data-node and one coordinator on each >> machine >> >> I tried to create some databases on each master to check if everything >> works ok, but I found a strange issue with one database that had been >> created only on one of the masters (while other databases I created and >> deleted afterwards were ok): >> >> postgres=# \l >> List of databases >> Name | Owner | Encoding | Collate | Ctype | Access >> privileges >> >> -----------+----------+----------+-------------+-------------+----------------------- >> postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> =c/postgres + >> | | | | | >> postgres=CTc/postgres >> template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> =c/postgres + >> | | | | | >> postgres=CTc/postgres >> test2 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> whatnot | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> >> vs >> >> postgres=# \l >> List of databases >> Name | Owner | Encoding | Collate | Ctype | Access >> privileges >> >> -----------+----------+----------+-------------+-------------+----------------------- >> postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> =c/postgres + >> | | | | | >> postgres=CTc/postgres >> template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> =c/postgres + >> | | | | | >> postgres=CTc/postgres >> whatnot | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> >> Unfortunately, when I try to perform any DDL command on a server that >> sees "test2" database I receive the following errors: >> >> postgres=# drop database test2; >> ERROR: database "test2" does not exist >> postgres=# create database test2; >> ERROR: database "test2" already exists >> >> Also, when I try to remove another database called "whatnot", drop >> operation never finishes. It looks like a transaction that hangs some DDL >> operations: >> >> postgres=# select * from pgxc_prepared_xacts; >> pgxc_prepared_xact >> -------------------- >> T74589 >> (1 row) >> >> postgres=# select * from pg_prepared_xacts; >> transaction | gid | prepared | owner | >> database >> >> -------------+--------+-------------------------------+----------+---------- >> 73716 | T73716 | 2015-07-09 12:58:25.823385+02 | postgres | >> postgres >> (1 row) >> >> postgres=# >> >> When I try to rollback the transaction, Postgres says that given GID does >> not exist. >> >> Is it a bug in Postgres XC? Is there a way to synchronize the masters? >> (eg delete "test2" on one master and "whatnot" on both of them). Please >> keep in mind that I created/dropped more databases without any issues, so >> I'm unsure what went wrong in case of these two specific databases. >> >> Cheers, >> >> Artur >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Don't Limit Your Business. Reach for the Cloud. >> GigeNET's Cloud Solutions provide you with the tools and support that >> you need to offload your IT needs and focus on growing your business. >> Configured For All Businesses. Start Your Cloud Today. >> https://www.gigenetcloud.com/ >> _______________________________________________ >> Postgres-xc-general mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >> >> > > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > > -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company |
|
From: Koichi S. <koi...@gm...> - 2015-07-10 04:13:37
|
In PGXC, DDL operation is not serialized, I mean, the order of the node where each peace of DDL executed is not defined. This may cause some race conditions and could cause local errors, resulting in inconsistent status. Recetly, I found CREATE TABLE in parallel schedule of regression test cause similar problems. I think this is common to XC and XL. There are a couple of ways to fix this: 1. Use coordinator primary node to go first, as done in replicated tables, 2. Serialize DDL execution, possibly by using advisory lock internally. Anyway, this is a bug and we need a fix. Solution 1 is bit more complicated than 2. Best; --- Koichi Suzuki https://www.linkedin.com/in/koichidbms 2015-07-09 23:22 GMT+09:00 Artur Graniszewski <aa...@bo...>: > Hi, > > I just finished the multi-master configuration of Postgres XC on my test > environment (three virtual machines): > > * VM1 - with GTM only > * VM2, VM2 - two masters with one data-node and one coordinator on each > machine > > I tried to create some databases on each master to check if everything > works ok, but I found a strange issue with one database that had been > created only on one of the masters (while other databases I created and > deleted afterwards were ok): > > postgres=# \l > List of databases > Name | Owner | Encoding | Collate | Ctype | Access > privileges > > -----------+----------+----------+-------------+-------------+----------------------- > postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > =c/postgres + > | | | | | > postgres=CTc/postgres > template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > =c/postgres + > | | | | | > postgres=CTc/postgres > test2 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > whatnot | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > > vs > > postgres=# \l > List of databases > Name | Owner | Encoding | Collate | Ctype | Access > privileges > > -----------+----------+----------+-------------+-------------+----------------------- > postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > =c/postgres + > | | | | | > postgres=CTc/postgres > template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > =c/postgres + > | | | | | > postgres=CTc/postgres > whatnot | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | > > Unfortunately, when I try to perform any DDL command on a server that sees > "test2" database I receive the following errors: > > postgres=# drop database test2; > ERROR: database "test2" does not exist > postgres=# create database test2; > ERROR: database "test2" already exists > > Also, when I try to remove another database called "whatnot", drop > operation never finishes. It looks like a transaction that hangs some DDL > operations: > > postgres=# select * from pgxc_prepared_xacts; > pgxc_prepared_xact > -------------------- > T74589 > (1 row) > > postgres=# select * from pg_prepared_xacts; > transaction | gid | prepared | owner | > database > > -------------+--------+-------------------------------+----------+---------- > 73716 | T73716 | 2015-07-09 12:58:25.823385+02 | postgres | postgres > (1 row) > > postgres=# > > When I try to rollback the transaction, Postgres says that given GID does > not exist. > > Is it a bug in Postgres XC? Is there a way to synchronize the masters? (eg > delete "test2" on one master and "whatnot" on both of them). Please keep in > mind that I created/dropped more databases without any issues, so I'm > unsure what went wrong in case of these two specific databases. > > Cheers, > > Artur > > > > > > > > > > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > > |
|
From: Artur G. <aa...@bo...> - 2015-07-09 14:39:55
|
Hi, I just finished the multi-master configuration of Postgres XC on my test environment (three virtual machines): * VM1 - with GTM only * VM2, VM2 - two masters with one data-node and one coordinator on each machine I tried to create some databases on each master to check if everything works ok, but I found a strange issue with one database that had been created only on one of the masters (while other databases I created and deleted afterwards were ok): postgres=# l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+-------------+-------------+----------------------- postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres test2 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | whatnot | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | vs postgres=# l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+-------------+-------------+----------------------- postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres whatnot | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | Unfortunately, when I try to perform any DDL command on a server that sees "test2" database I receive the following errors: postgres=# drop database test2; ERROR: database "test2" does not exist postgres=# create database test2; ERROR: database "test2" already exists Also, when I try to remove another database called "whatnot", drop operation never finishes. It looks like a transaction that hangs some DDL operations: postgres=# select * from pgxc_prepared_xacts; pgxc_prepared_xact -------------------- T74589 (1 row) postgres=# select * from pg_prepared_xacts; transaction | gid | prepared | owner | database -------------+--------+-------------------------------+----------+---------- 73716 | T73716 | 2015-07-09 12:58:25.823385+02 | postgres | postgres (1 row) postgres=# When I try to rollback the transaction, Postgres says that given GID does not exist. Is it a bug in Postgres XC? Is there a way to synchronize the masters? (eg delete "test2" on one master and "whatnot" on both of them). Please keep in mind that I created/dropped more databases without any issues, so I'm unsure what went wrong in case of these two specific databases. Cheers, Artur |
