postgres-xc-developers Mailing List for Postgres-XC

Hi,

I took the time to make a couple of tests with the patch attached which is
the latest version.
As it is not necessary to set password values in connection strings for
users to have an access to the data in the cluster, I removed that in the
patch attached, making it a little bit simplified.

Besides, I made a couple of tests with several users in the cluster.
I made it with a cluster having 2 Coordinators, with ports 5432 (Co1) and
5452 (Co2).
The 2 users are called ioltas and toto.

1) After building the cluster, if the role is not created:
toto@oltania:~$ psql -p 5452 template1
psql: FATAL:  role "toto" does not exist

2) ioltas is a superuser, so it creates a new role and a table from
Coordinator 1:
ioltas@oltania:~/pgsql$ psql template1
psql (9.0.3)
Type "help" for help.
template1=# create role toto login;
CREATE ROLE
template1=# create table aa (a int);
CREATE TABLE
template1=# insert into aa values (1),(2);
INSERT 0 2

3) then toto can login but cannot access the table:
toto@oltania:~$ psql -p 5452 template1
psql (9.0.3)
Type "help" for help.
template1=> select * from aa;
ERROR:  permission denied for relation aa
template1=> \dp aa
                          Access privileges
 Schema | Name | Type  | Access privileges | Column access privileges
--------+------+-------+-------------------+--------------------------
 public | aa   | table |                   |
(1 row)

4) grant access to the table aa for toto from Coordinator 1 (superuser
ioltas)
template1=# grant select on table aa to toto;
GRANT

5) Then table access is granted for user toto:
template1=> \dp aa
                            Access privileges
 Schema | Name | Type  |   Access privileges   | Column access privileges
--------+------+-------+-----------------------+--------------------------
 public | aa   | table | ioltas=arwdDxt/ioltas+|
        |      |       | toto=r/ioltas         |
(1 row)
template1=> select * from aa;
 a
---
 1
 2
(2 rows)

6) by doing a ps, connections for both users exist
ioltas@oltania:~/pgxc$ ps ux | grep template1 | cut -d " " -f 30-
ioltas template1 [local] idle
ioltas template1 ::1(55384) idle
ioltas template1 ::1(48039) idle
ioltas template1 ::1(57169) idle
toto template1 [local] idle
toto template1 ::1(55396) idle
toto template1 ::1(48051) idle

7) CLEAN CONNECTION  is also available to close pooler connections:
for user toto:
template1=> clean connection to all for database template1;
ERROR:  must be superuser to clean pool connections
for superuser ioltas:
template1=# clean connection to all for database template1;
CLEAN CONNECTION

CLEAN CONNECTION cleans up connections for all users on the chosen database.
So, any comments?
-- 
Michael Paquier
http://michael.otacoo.com

Thanks for fixing this issue.
Such patches are always very helpful.

Regards,
-- 
Michael Paquier
http://michael.otacoo.com

Hi all,

Postgres-XC's pooler just supports single user.
And this single user needs to set coord_user, coord_passwd, data_node_user
and data_node_passwd
in order to be able to have a full access to the cluster.

This limits the usage of cluster to 1 user, and putting password data inside
postgresql.conf
is a severe security hole.

Attached is a patch that extends the pooler to support multiple users. This
is perhaps the most important implementation since DDL synchronizing.
You can think of it as the first step of implementation of session
parameters.
Imagine that you create a role like this:
CREATE ROLE foo SUPERUSER LOGIN;
This user is able with the patch attached to login in the cluster and make
normal operations.

With this patch user and password parameters in postgresql.conf are removed!

This patch has now 1 restriction:
pooler supports only superusers. This means that if a user needs a password
to connect he cannot get pooler connections.

As I am not very familiar with password system in Postgres, I'd like to have
your opinion about how to safely get a password for a given user, and make a
connection with it. I saw some encryption protocol with md5 but perhaps
there is a good way to do taht with libpq.
I am not talking yet about adding secured connection protocol to pooler
(ssl, etc.). This may be a next step.

Also, the patch attached does not support that, but I would like to use the
database Oid and user Oid to manage the database pools for XC.
Using Oid for users makes sense as it hugely facilitates the user management
instead of having a simple string.
For Databases, it reduces the amount of data exchanged between pooler and
postmaster children, so I think it is worth to make such a modification.
What do you think about that?

Thanks,
-- 
Michael Paquier
http://michael.otacoo.com

patch again for 'make -j' issue on current HEAD.

Wang Diancheng <dia...@gm...> writes:

> dear all,
>
> attached patch fix 2 problems:
>
> 1. make -j broken
> 2. install pgxc headers when make install, utils/rel.h and other headers
> depend on it. 
>

Hi,

This is very similar to function issue.    So far, as much as we think
about rules behind views, I think we can assume they're just for
coordinators.

In the future, users may want to have rules on datanodes.   In this
case, users should have good background of row distribution and
coordinator - datanode communication.    We may want to provide such 
information in the reference manual.

Regards;
----
Koichi Suzuki

On Wed, 30 Mar 2011 02:00:10 +0900
Michael Paquier <mic...@gm...> wrote:

> Hi all,
> 
> I was wondering something.
> Firing rules consist in doing a DML operation or nothing depending on the
> query being done.
> Basically, firing a rule may be enough only on Coordinators, no?
> 
> With this assumption, defining rules only on Coordinators is enough.
> What do you think about that?
> Do you have in mind any example that may need firing rules on Datanodes?
> I am not talking about performance issues.
> 
> I am asking that because of bug 3237820 where a rule is defined on a view.
> Views are only created on Coordinators, and rules are defined on both
> Coordinator and Datanodes.
> 
> Thanks,
> -- 
> Michael Paquier
> http://michael.otacoo.com

Hi all,

I was wondering something.
Firing rules consist in doing a DML operation or nothing depending on the
query being done.
Basically, firing a rule may be enough only on Coordinators, no?

With this assumption, defining rules only on Coordinators is enough.
What do you think about that?
Do you have in mind any example that may need firing rules on Datanodes?
I am not talking about performance issues.

I am asking that because of bug 3237820 where a rule is defined on a view.
Views are only created on Coordinators, and rules are defined on both
Coordinator and Datanodes.

Thanks,
-- 
Michael Paquier
http://michael.otacoo.com

Sorry, not 27 tests, but 47 tests were failing on the regressions of the
26th.

On Tue, Mar 29, 2011 at 3:12 AM, Michael Paquier
<mic...@gm...>wrote:

> Hi all,
>
> Here are the latest regression test results.
> 46 tests are failing.
> On the 26th, 27 tests were failing.
>
> Regards,
> --
> Michael Paquier
> http://michael.otacoo.com
>
>


-- 
Michael Paquier
http://michael.otacoo.com

OK, understood,
so it is still necessary to fix view creation because it is only launched on
the coordinator external application is connected to.
DROP VIEW is launched on all the nodes.

I'll write a patch to fix that asap, it is not very complicated.
Thanks,

Michael

On Sun, Mar 27, 2011 at 11:59 PM, Andrei Martsinchyk <
and...@gm...> wrote:

> Michael,
>
> Yes, CREATE/DROP VIEW should be executed on coordinators only.
>
> 27.03.2011 17:50 пользователь "Michael" <mic...@gm...>
> написал:
>
>  Thanks for your answer, Andrei.
>
> With current code, I saw that DROP VIEW was done on all the nodes when
> launched
> and not only on remote Coordinator.
> For example, now DROP VIEW fails because it is passed down to backend nodes
> and the view previously created on Coordinator is not dropped.
> As you mean, it is correct to launch DROP VIEW only on remote Coordinator,
> no?
>
>
>
> (2011年03月27日 18:20), Andrei Martsinchyk wrote:
> >
> > This is correct. Data node can not access data ...
> --
> Michael
> michael.otacoo.com
>
>


-- 
Michael Paquier
http://michael.otacoo.com

Michael,

Yes, CREATE/DROP VIEW should be executed on coordinators only.

27.03.2011 17:50 пользователь "Michael" <mic...@gm...> написал:

 Thanks for your answer, Andrei.

With current code, I saw that DROP VIEW was done on all the nodes when
launched
and not only on remote Coordinator.
For example, now DROP VIEW fails because it is passed down to backend nodes
and the view previously created on Coordinator is not dropped.
As you mean, it is correct to launch DROP VIEW only on remote Coordinator,
no?



(2011年03月27日 18:20), Andrei Martsinchyk wrote:
>
> This is correct. Data node can not access data ...
-- 
Michael
michael.otacoo.com

Thanks for your answer, Andrei.

With current code, I saw that DROP VIEW was done on all the nodes when 
launched
and not only on remote Coordinator.
For example, now DROP VIEW fails because it is passed down to backend 
nodes and the view previously created on Coordinator is not dropped.
As you mean, it is correct to launch DROP VIEW only on remote 
Coordinator, no?

(2011年03月27日 18:20), Andrei Martsinchyk wrote:
> This is correct. Data node can not access data on other nodes, so data 
> node view would be on local portions of tables involved. Sometimes 
> that is consistent, but in general not.
-- 
Michael
michael.otacoo.com <http://michael.otacoo.com>

Michael,

This is correct. Data node can not access data on other nodes, so data node
view would be on local portions of tables involved. Sometimes that is
consistent, but in general not.

27.03.2011 11:25 пользователь "Michael Paquier" <mic...@gm...>
написал:

Hi,

I saw in the current code that views are only created on remote Coordinator,
the current code does not use ExecRemoteutility to spread the query to other
nodes, including other Coordinators?

Is it normal?
I would think that a view has to be created on all the nodes, no?
Only on Coordinator?

Regards,
-- 
Michael Paquier
http://michael.otacoo.com


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Postgres-xc-developers mailing list
Pos...@li...
https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

Hi,

I saw in the current code that views are only created on remote Coordinator,
the current code does not use ExecRemoteutility to spread the query to other
nodes, including other Coordinators?

Is it normal?
I would think that a view has to be created on all the nodes, no?
Only on Coordinator?

Regards,
-- 
Michael Paquier
http://michael.otacoo.com

Sorry about that,
I pushed an incorrect commit about without_oid.
I deleted this commit but now the repository is back to normal, branch
merge_postgres_9_0_3 is available again.

My apologies once again for the inconvenience.
-- 
Michael Paquier
http://michael.otacoo.com

Hi all,

Since version 0.9.3 and DDL synchronization, pgxc_ddl is not necessary by
default
when launching DDL in the cluster.

Prior to 0.9.2, DDL was only run on only 1 Coordinator and it was necessary
to copy manually catalog files
to have consistent catalog info in the cluster.
pgxc_ddl automatized that by running DDL on a remote Coordinator, stop all
the Coordinators,
copy the catalog files and then restart the Coordinators.

This resulted in a additional configuration file called pgxc.conf containing
Coordinator information
and initdb was modified a litte bit to install also this new configuration
file.
Here is a patch to clean up that.

With this patch pgxc_ddl is stored in the folder src/pgxc/bin/pgxc_ddl and
this script is not installed by default.
If there are comments, feel free to share them.
If it is OK, I'd like commit that soon in the master branch and then merge
ha_support and merge_postgres_9_0_3 branch.

Thanks,
-- 
Michael Paquier
http://michael.otacoo.com

At the current implementation, we don't have distinction between local
and global foreign key.   We've discussed that we may need two degree
of constraint, namely, local and global.   Unfortunately, we don't
have this distinction now.

Until we have this distinction and safer support for the local
constraint, I think we should block this for a while.

Or many people will experience XC server crash, as seen in the regression.

This should also be applied to primary keys which are not distribution key.
----------
Koichi Suzuki



2011/3/8 Mason <ma...@us...>:
> Locally enforceable foreign key constraints are no longer supported?  :-(
>
> If there is a pg_regress failure, I think it is better to fix it than
> simply block this feature. Is it a difficult issue?
>
>
> ---------- Forwarded message ----------
> From: Michael Paquier <mic...@us...>
> Date: Tue, Mar 8, 2011 at 12:16 AM
> Subject: [Postgres-xc-committers] Postgres-XC branch,
> merge_postgres_9_0_3, updated. v0.9.3-78-g3af192a
> To: pos...@li...
>
>
> Project "Postgres-XC".
>
> The branch, merge_postgres_9_0_3 has been updated
>       via  3af192ad45f2e21a74d032faa4612259606aa266 (commit)
>      from  ab949a7cb237c6966a19204b23aea6c931928961 (commit)
>
>
> - Log -----------------------------------------------------------------
> commit 3af192ad45f2e21a74d032faa4612259606aa266
> Author: Michael P <mic...@us...>
> Date:   Tue Mar 8 14:14:11 2011 +0900
>
>    Block FOREIGN constraint creation
>
>    This prevents a crash in truncate test of pg_regress.
>    Correct error messages for non-supported features.
>
> diff --git a/src/backend/parser/parse_utilcmd.c
> b/src/backend/parser/parse_utilcmd.c
> index 822ca0b..30f5cd9 100644
> --- a/src/backend/parser/parse_utilcmd.c
> +++ b/src/backend/parser/parse_utilcmd.c
> @@ -1585,6 +1585,12 @@ transformFKConstraints(ParseState *pstate,
> CreateStmtContext *cxt,
>
>                        constraint->skip_validation = true;
>  #ifdef PGXC
> +                       if (constraint->contype == CONSTR_FOREIGN)
> +                               ereport(ERROR,
> +
> (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> +                                                errmsg("Postgres-XC
> does not support FOREIGN constraints yet"),
> +                                                errdetail("The
> feature is not currently supported")));
> +
>                        /*
>                         * Set fallback distribution column.
>                         * If not yet set, set it to first column in FK
> constraint
> diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
> index a48c4a3..3ff5ced 100644
> --- a/src/backend/tcop/utility.c
> +++ b/src/backend/tcop/utility.c
> @@ -807,7 +807,8 @@ standard_ProcessUtility(Node *parsetree,
>  #ifdef PGXC
>                        ereport(ERROR,
>                                        (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> -                                        errmsg("PREPARE is not supported")));
> +                                        errmsg("Postgres-XC does not
> support PREPARE yet"),
> +                                        errdetail("The feature is not
> currently supported")));
>  #endif
>                        CheckRestrictedOperation("PREPARE");
>                        PrepareQuery((PrepareStmt *) parsetree, queryString);
> @@ -817,7 +818,8 @@ standard_ProcessUtility(Node *parsetree,
>  #ifdef PGXC
>                        ereport(ERROR,
>                                        (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> -                                        errmsg("EXECUTE is not supported")));
> +                                        errmsg("Postgres-XC does not
> support EXECUTE yet"),
> +                                        errdetail("The feature is not
> currently supported")));
>  #endif
>                        ExecuteQuery((ExecuteStmt *) parsetree,
> queryString, params,
>                                                 dest, completionTag);
> @@ -1062,8 +1064,8 @@ standard_ProcessUtility(Node *parsetree,
>                                {
>                                        ereport(ERROR,
>
> (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> -                                               errmsg("PGXC does not
> support concurrent indexes"),
> -                                               errdetail("The feature
> is not currently supported")));
> +                                                errmsg("PGXC does not
> support concurrent INDEX yet"),
> +                                                errdetail("The
> feature is not currently supported")));
>                                }
>  #endif
>
> @@ -1311,7 +1313,8 @@ standard_ProcessUtility(Node *parsetree,
>                        /* Postgres-XC does not support yet triggers */
>                        ereport(ERROR,
>                                        (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> -                                        errmsg("TRIGGER is not supported")));
> +                                        errmsg("Postgres-XC does not
> support TRIGGER yet"),
> +                                        errdetail("The feature is not
> currently supported")));
>
>                        if (IS_PGXC_COORDINATOR)
>                                ExecUtilityStmtOnNodes(queryString,
> NULL, false, EXEC_ON_ALL_NODES);
>
> -----------------------------------------------------------------------
>
> Summary of changes:
>  src/backend/parser/parse_utilcmd.c |    6 ++++++
>  src/backend/tcop/utility.c         |   13 ++++++++-----
>  2 files changed, 14 insertions(+), 5 deletions(-)
>
>
> hooks/post-receive
> --
> Postgres-XC
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Postgres-xc-committers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-committers
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

Locally enforceable foreign key constraints are no longer supported?  :-(

If there is a pg_regress failure, I think it is better to fix it than
simply block this feature. Is it a difficult issue?


---------- Forwarded message ----------
From: Michael Paquier <mic...@us...>
Date: Tue, Mar 8, 2011 at 12:16 AM
Subject: [Postgres-xc-committers] Postgres-XC branch,
merge_postgres_9_0_3, updated. v0.9.3-78-g3af192a
To: pos...@li...


Project "Postgres-XC".

The branch, merge_postgres_9_0_3 has been updated
      via  3af192ad45f2e21a74d032faa4612259606aa266 (commit)
     from  ab949a7cb237c6966a19204b23aea6c931928961 (commit)


- Log -----------------------------------------------------------------
commit 3af192ad45f2e21a74d032faa4612259606aa266
Author: Michael P <mic...@us...>
Date:   Tue Mar 8 14:14:11 2011 +0900

   Block FOREIGN constraint creation

   This prevents a crash in truncate test of pg_regress.
   Correct error messages for non-supported features.

diff --git a/src/backend/parser/parse_utilcmd.c
b/src/backend/parser/parse_utilcmd.c
index 822ca0b..30f5cd9 100644
--- a/src/backend/parser/parse_utilcmd.c
+++ b/src/backend/parser/parse_utilcmd.c
@@ -1585,6 +1585,12 @@ transformFKConstraints(ParseState *pstate,
CreateStmtContext *cxt,

                       constraint->skip_validation = true;
 #ifdef PGXC
+                       if (constraint->contype == CONSTR_FOREIGN)
+                               ereport(ERROR,
+
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+                                                errmsg("Postgres-XC
does not support FOREIGN constraints yet"),
+                                                errdetail("The
feature is not currently supported")));
+
                       /*
                        * Set fallback distribution column.
                        * If not yet set, set it to first column in FK
constraint
diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
index a48c4a3..3ff5ced 100644
--- a/src/backend/tcop/utility.c
+++ b/src/backend/tcop/utility.c
@@ -807,7 +807,8 @@ standard_ProcessUtility(Node *parsetree,
 #ifdef PGXC
                       ereport(ERROR,
                                       (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
-                                        errmsg("PREPARE is not supported")));
+                                        errmsg("Postgres-XC does not
support PREPARE yet"),
+                                        errdetail("The feature is not
currently supported")));
 #endif
                       CheckRestrictedOperation("PREPARE");
                       PrepareQuery((PrepareStmt *) parsetree, queryString);
@@ -817,7 +818,8 @@ standard_ProcessUtility(Node *parsetree,
 #ifdef PGXC
                       ereport(ERROR,
                                       (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
-                                        errmsg("EXECUTE is not supported")));
+                                        errmsg("Postgres-XC does not
support EXECUTE yet"),
+                                        errdetail("The feature is not
currently supported")));
 #endif
                       ExecuteQuery((ExecuteStmt *) parsetree,
queryString, params,
                                                dest, completionTag);
@@ -1062,8 +1064,8 @@ standard_ProcessUtility(Node *parsetree,
                               {
                                       ereport(ERROR,

(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
-                                               errmsg("PGXC does not
support concurrent indexes"),
-                                               errdetail("The feature
is not currently supported")));
+                                                errmsg("PGXC does not
support concurrent INDEX yet"),
+                                                errdetail("The
feature is not currently supported")));
                               }
 #endif

@@ -1311,7 +1313,8 @@ standard_ProcessUtility(Node *parsetree,
                       /* Postgres-XC does not support yet triggers */
                       ereport(ERROR,
                                       (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
-                                        errmsg("TRIGGER is not supported")));
+                                        errmsg("Postgres-XC does not
support TRIGGER yet"),
+                                        errdetail("The feature is not
currently supported")));

                       if (IS_PGXC_COORDINATOR)
                               ExecUtilityStmtOnNodes(queryString,
NULL, false, EXEC_ON_ALL_NODES);

-----------------------------------------------------------------------

Summary of changes:
 src/backend/parser/parse_utilcmd.c |    6 ++++++
 src/backend/tcop/utility.c         |   13 ++++++++-----
 2 files changed, 14 insertions(+), 5 deletions(-)


hooks/post-receive
--
Postgres-XC

------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
Postgres-xc-committers mailing list
Pos...@li...
https://lists.sourceforge.net/lists/listinfo/postgres-xc-committers

Hi all,

Now XC has no way to delete a sequence on GTM when a transaction, which
created this sequence, is rollbacked.
In a more general case, there is no transaction control for sequence on GTM.

For the time being and code stability, what do you think about blocking
sequence DDL inside transaction block?
Regards,
-- 
Michael Paquier
http://michael.otacoo.com

Hi,

I found a bug with INSERT SELECT when digging into the regression tests.
This is reported in bug 3202464.
https://sourceforge.net/tracker/index.php?func=detail&aid=3202464&group_id=311227&atid=1310232

If INSERT SELECT doesn't pass the regression tests, is it better to block it
for the time being until it is fully supported or not?
I thought we added support for that a couple of months ago, it may have been
broken at some point.
-- 
Michael Paquier
http://michael.otacoo.com

Drawback of the current specification is that the default does not
work in all cases, especially when PRIMARY key is explicitly given to
the second or latter columns, or non-suitable attribute column is
specified first.

I think default should work in (almost) all the simple cases and
current is not novice-users friendly.

We can advice users as the response that the table is going to be
replicated and will not write-scale.

Or we may be able to make DISTRIBUTE BY not optional.
----------
Koichi Suzuki



2011/3/8 Mason Sharp <mas...@gm...>:
> On Mon, Mar 7, 2011 at 6:13 PM, Michael Paquier
> <mic...@gm...> wrote:
>> Users can also use the keywords for distribution about that.
>> I was hoping this would help reducing the number of diff obtained with
>> regression tests.
>
> I would still back it out, since the existing code does a pretty good
> job if they do not specify anything and will give first time users
> better performance if they run existing SQL scripts without modifying
> them.
>
> If there are regression differences, then I think it is good to know
> about them and fix them instead of just switching to replicated tables
> by default.
>
> Regards,
>
> Mason
>
>
>>
>> On Mon, Mar 7, 2011 at 8:23 PM, Mason <ma...@us...> wrote:
>>>
>>> I just emailed about this. I think this is not a good idea (just try
>>> running DBT-1 without any distribution clauses). I recommend backing
>>> this out
>>>
>>> Mason
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Michael Paquier <mic...@us...>
>>> Date: Mon, Mar 7, 2011 at 2:15 AM
>>> Subject: [Postgres-xc-committers] Postgres-XC branch,
>>> merge_postgres_9_0_3, updated. v0.9.3-65-gfa427af
>>> To: pos...@li...
>>>
>>>
>>> Project "Postgres-XC".
>>>
>>> The branch, merge_postgres_9_0_3 has been updated
>>>       via  fa427af446193741501c72e6e026ac493a125137 (commit)
>>>       via  a6a956e4d1303161750161c0629adb1b4514d345 (commit)
>>>       via  33342d8d44bb2c36239712d9e7318df0776ce018 (commit)
>>>      from  9ecde28ad6b6ed00b7588928480bf0bd8a741421 (commit)
>>>
>>>
>>> - Log -----------------------------------------------------------------
>>> commit fa427af446193741501c72e6e026ac493a125137
>>> Author: Michael P <mic...@us...>
>>> Date:   Mon Mar 7 16:09:54 2011 +0900
>>>
>>>    CREATE TABLE default distribution to REPLICATED
>>>
>>>    Change distribution type of table to REPLICATED when no
>>>    distribution is specified like with:
>>>    CREATE TABLE aa (int a);
>>>
>>> diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
>>> index 59231a8..ea20e66 100644
>>> --- a/src/backend/catalog/heap.c
>>> +++ b/src/backend/catalog/heap.c
>>> @@ -874,34 +874,17 @@ AddRelationDistribution (Oid relid,
>>>                                                 errmsg("Invalid parent
>>> table distribution type")));
>>>                                        break;
>>>                        }
>>> -               } else
>>> +               }
>>> +               else
>>>                {
>>>                        /*
>>>                         * If no distribution was specified, and we
>>> have not chosen
>>> -                        * one based on primary key or foreign key,
>>> use first column with
>>> -                        * a supported data type.
>>> +                        * distribute table by replication.
>>>                         */
>>> -                       Form_pg_attribute attr;
>>> -                       int i;
>>> -
>>> -                       locatortype = LOCATOR_TYPE_HASH;
>>> -
>>> -                       for (i = 0; i < descriptor->natts; i++)
>>> -                       {
>>> -                               attr = descriptor->attrs[i];
>>> -                               if (IsHashDistributable(attr->atttypid))
>>> -                               {
>>> -                                       /* distribute on this column */
>>> -                                       attnum = i + 1;
>>> -                                       break;
>>> -                               }
>>> -                       }
>>> -
>>> -                       /* If we did not find a usable type, fall back
>>> to round robin */
>>> -                       if (attnum == 0)
>>> -                               locatortype = LOCATOR_TYPE_RROBIN;
>>> +                       locatortype = LOCATOR_TYPE_REPLICATED;
>>>                }
>>> -       } else
>>> +       }
>>> +       else
>>>        {
>>>                /*
>>>                 * User specified distribution type
>>>
>>> commit a6a956e4d1303161750161c0629adb1b4514d345
>>> Author: Michael P <mic...@us...>
>>> Date:   Mon Mar 7 16:00:16 2011 +0900
>>>
>>>    Block PREPARE and EXECUTE for the time being
>>>
>>>    It has been noticed that PREPARE crashed the server in some pg_regress
>>>    test cases.
>>>
>>> diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
>>> index 1240614..bf122db 100644
>>> --- a/src/backend/tcop/utility.c
>>> +++ b/src/backend/tcop/utility.c
>>> @@ -804,11 +804,21 @@ standard_ProcessUtility(Node *parsetree,
>>>                        break;
>>>
>>>                case T_PrepareStmt:
>>> +#ifdef PGXC
>>> +                       ereport(ERROR,
>>> +
>>> (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>>> +                                        errmsg("PREPARE is not
>>> supported")));
>>> +#endif
>>>                        CheckRestrictedOperation("PREPARE");
>>>                        PrepareQuery((PrepareStmt *) parsetree,
>>> queryString);
>>>                        break;
>>>
>>>                case T_ExecuteStmt:
>>> +#ifdef PGXC
>>> +                       ereport(ERROR,
>>> +
>>> (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>>> +                                        errmsg("EXECUTE is not
>>> supported")));
>>> +#endif
>>>                        ExecuteQuery((ExecuteStmt *) parsetree,
>>> queryString, params,
>>>                                                 dest, completionTag);
>>>                        break;
>>>
>>> commit 33342d8d44bb2c36239712d9e7318df0776ce018
>>> Author: Michael P <mic...@us...>
>>> Date:   Mon Mar 7 15:58:13 2011 +0900
>>>
>>>    Fix for CREATE INDEX CONCURRENTLY
>>>
>>>    When an index is created concurrently, Coordinator tried to take
>>>    a snapshot that had already been deleted.
>>>    We need to take a new one from Coordinator.
>>>
>>>    Patch written by Abbas Butt
>>>
>>> diff --git a/src/backend/utils/time/snapmgr.c
>>> b/src/backend/utils/time/snapmgr.c
>>> index a735fc3..8140321 100644
>>> --- a/src/backend/utils/time/snapmgr.c
>>> +++ b/src/backend/utils/time/snapmgr.c
>>> @@ -34,7 +34,9 @@
>>>  #include "utils/resowner.h"
>>>  #include "utils/snapmgr.h"
>>>  #include "utils/tqual.h"
>>> -
>>> +#ifdef PGXC
>>> +#include "pgxc/pgxc.h"
>>> +#endif
>>>
>>>  /*
>>>  * CurrentSnapshot points to the only snapshot taken in a serializable
>>> @@ -344,6 +346,14 @@ PopActiveSnapshot(void)
>>>  Snapshot
>>>  GetActiveSnapshot(void)
>>>  {
>>> +#ifdef PGXC
>>> +       /*
>>> +        * Check if topmost snapshot is null or not,
>>> +        * if it is, a new one will be taken from GTM.
>>> +        */
>>> +       if (!ActiveSnapshot && IS_PGXC_COORDINATOR && !IsConnFromCoord())
>>> +               return NULL;
>>> +#endif
>>>        Assert(ActiveSnapshot != NULL);
>>>
>>>        return ActiveSnapshot->as_snap;
>>>
>>> -----------------------------------------------------------------------
>>>
>>> Summary of changes:
>>>  src/backend/catalog/heap.c       |   29 ++++++-----------------------
>>>  src/backend/tcop/utility.c       |   10 ++++++++++
>>>  src/backend/utils/time/snapmgr.c |   12 +++++++++++-
>>>  3 files changed, 27 insertions(+), 24 deletions(-)
>>>
>>>
>>> hooks/post-receive
>>> --
>>> Postgres-XC
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> What You Don't Know About Data Connectivity CAN Hurt You
>>> This paper provides an overview of data connectivity, details
>>> its effect on application quality, and explores various alternative
>>> solutions. http://p.sf.net/sfu/progress-d2d
>>> _______________________________________________
>>> Postgres-xc-committers mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-committers
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> What You Don't Know About Data Connectivity CAN Hurt You
>>> This paper provides an overview of data connectivity, details
>>> its effect on application quality, and explores various alternative
>>> solutions. http://p.sf.net/sfu/progress-d2d
>>> _______________________________________________
>>> Postgres-xc-developers mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>
>>
>>
>> --
>> Michael Paquier
>> http://michael.otacoo.com
>>
>>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

On Mon, Mar 7, 2011 at 6:13 PM, Michael Paquier
<mic...@gm...> wrote:
> Users can also use the keywords for distribution about that.
> I was hoping this would help reducing the number of diff obtained with
> regression tests.

I would still back it out, since the existing code does a pretty good
job if they do not specify anything and will give first time users
better performance if they run existing SQL scripts without modifying
them.

If there are regression differences, then I think it is good to know
about them and fix them instead of just switching to replicated tables
by default.

Regards,

Mason


>
> On Mon, Mar 7, 2011 at 8:23 PM, Mason <ma...@us...> wrote:
>>
>> I just emailed about this. I think this is not a good idea (just try
>> running DBT-1 without any distribution clauses). I recommend backing
>> this out
>>
>> Mason
>>
>>
>> ---------- Forwarded message ----------
>> From: Michael Paquier <mic...@us...>
>> Date: Mon, Mar 7, 2011 at 2:15 AM
>> Subject: [Postgres-xc-committers] Postgres-XC branch,
>> merge_postgres_9_0_3, updated. v0.9.3-65-gfa427af
>> To: pos...@li...
>>
>>
>> Project "Postgres-XC".
>>
>> The branch, merge_postgres_9_0_3 has been updated
>>       via  fa427af446193741501c72e6e026ac493a125137 (commit)
>>       via  a6a956e4d1303161750161c0629adb1b4514d345 (commit)
>>       via  33342d8d44bb2c36239712d9e7318df0776ce018 (commit)
>>      from  9ecde28ad6b6ed00b7588928480bf0bd8a741421 (commit)
>>
>>
>> - Log -----------------------------------------------------------------
>> commit fa427af446193741501c72e6e026ac493a125137
>> Author: Michael P <mic...@us...>
>> Date:   Mon Mar 7 16:09:54 2011 +0900
>>
>>    CREATE TABLE default distribution to REPLICATED
>>
>>    Change distribution type of table to REPLICATED when no
>>    distribution is specified like with:
>>    CREATE TABLE aa (int a);
>>
>> diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
>> index 59231a8..ea20e66 100644
>> --- a/src/backend/catalog/heap.c
>> +++ b/src/backend/catalog/heap.c
>> @@ -874,34 +874,17 @@ AddRelationDistribution (Oid relid,
>>                                                 errmsg("Invalid parent
>> table distribution type")));
>>                                        break;
>>                        }
>> -               } else
>> +               }
>> +               else
>>                {
>>                        /*
>>                         * If no distribution was specified, and we
>> have not chosen
>> -                        * one based on primary key or foreign key,
>> use first column with
>> -                        * a supported data type.
>> +                        * distribute table by replication.
>>                         */
>> -                       Form_pg_attribute attr;
>> -                       int i;
>> -
>> -                       locatortype = LOCATOR_TYPE_HASH;
>> -
>> -                       for (i = 0; i < descriptor->natts; i++)
>> -                       {
>> -                               attr = descriptor->attrs[i];
>> -                               if (IsHashDistributable(attr->atttypid))
>> -                               {
>> -                                       /* distribute on this column */
>> -                                       attnum = i + 1;
>> -                                       break;
>> -                               }
>> -                       }
>> -
>> -                       /* If we did not find a usable type, fall back
>> to round robin */
>> -                       if (attnum == 0)
>> -                               locatortype = LOCATOR_TYPE_RROBIN;
>> +                       locatortype = LOCATOR_TYPE_REPLICATED;
>>                }
>> -       } else
>> +       }
>> +       else
>>        {
>>                /*
>>                 * User specified distribution type
>>
>> commit a6a956e4d1303161750161c0629adb1b4514d345
>> Author: Michael P <mic...@us...>
>> Date:   Mon Mar 7 16:00:16 2011 +0900
>>
>>    Block PREPARE and EXECUTE for the time being
>>
>>    It has been noticed that PREPARE crashed the server in some pg_regress
>>    test cases.
>>
>> diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
>> index 1240614..bf122db 100644
>> --- a/src/backend/tcop/utility.c
>> +++ b/src/backend/tcop/utility.c
>> @@ -804,11 +804,21 @@ standard_ProcessUtility(Node *parsetree,
>>                        break;
>>
>>                case T_PrepareStmt:
>> +#ifdef PGXC
>> +                       ereport(ERROR,
>> +
>> (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>> +                                        errmsg("PREPARE is not
>> supported")));
>> +#endif
>>                        CheckRestrictedOperation("PREPARE");
>>                        PrepareQuery((PrepareStmt *) parsetree,
>> queryString);
>>                        break;
>>
>>                case T_ExecuteStmt:
>> +#ifdef PGXC
>> +                       ereport(ERROR,
>> +
>> (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>> +                                        errmsg("EXECUTE is not
>> supported")));
>> +#endif
>>                        ExecuteQuery((ExecuteStmt *) parsetree,
>> queryString, params,
>>                                                 dest, completionTag);
>>                        break;
>>
>> commit 33342d8d44bb2c36239712d9e7318df0776ce018
>> Author: Michael P <mic...@us...>
>> Date:   Mon Mar 7 15:58:13 2011 +0900
>>
>>    Fix for CREATE INDEX CONCURRENTLY
>>
>>    When an index is created concurrently, Coordinator tried to take
>>    a snapshot that had already been deleted.
>>    We need to take a new one from Coordinator.
>>
>>    Patch written by Abbas Butt
>>
>> diff --git a/src/backend/utils/time/snapmgr.c
>> b/src/backend/utils/time/snapmgr.c
>> index a735fc3..8140321 100644
>> --- a/src/backend/utils/time/snapmgr.c
>> +++ b/src/backend/utils/time/snapmgr.c
>> @@ -34,7 +34,9 @@
>>  #include "utils/resowner.h"
>>  #include "utils/snapmgr.h"
>>  #include "utils/tqual.h"
>> -
>> +#ifdef PGXC
>> +#include "pgxc/pgxc.h"
>> +#endif
>>
>>  /*
>>  * CurrentSnapshot points to the only snapshot taken in a serializable
>> @@ -344,6 +346,14 @@ PopActiveSnapshot(void)
>>  Snapshot
>>  GetActiveSnapshot(void)
>>  {
>> +#ifdef PGXC
>> +       /*
>> +        * Check if topmost snapshot is null or not,
>> +        * if it is, a new one will be taken from GTM.
>> +        */
>> +       if (!ActiveSnapshot && IS_PGXC_COORDINATOR && !IsConnFromCoord())
>> +               return NULL;
>> +#endif
>>        Assert(ActiveSnapshot != NULL);
>>
>>        return ActiveSnapshot->as_snap;
>>
>> -----------------------------------------------------------------------
>>
>> Summary of changes:
>>  src/backend/catalog/heap.c       |   29 ++++++-----------------------
>>  src/backend/tcop/utility.c       |   10 ++++++++++
>>  src/backend/utils/time/snapmgr.c |   12 +++++++++++-
>>  3 files changed, 27 insertions(+), 24 deletions(-)
>>
>>
>> hooks/post-receive
>> --
>> Postgres-XC
>>
>>
>> ------------------------------------------------------------------------------
>> What You Don't Know About Data Connectivity CAN Hurt You
>> This paper provides an overview of data connectivity, details
>> its effect on application quality, and explores various alternative
>> solutions. http://p.sf.net/sfu/progress-d2d
>> _______________________________________________
>> Postgres-xc-committers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-committers
>>
>>
>> ------------------------------------------------------------------------------
>> What You Don't Know About Data Connectivity CAN Hurt You
>> This paper provides an overview of data connectivity, details
>> its effect on application quality, and explores various alternative
>> solutions. http://p.sf.net/sfu/progress-d2d
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>
>
> --
> Michael Paquier
> http://michael.otacoo.com
>
>

Users can also use the keywords for distribution about that.
I was hoping this would help reducing the number of diff obtained with
regression tests.

On Mon, Mar 7, 2011 at 8:23 PM, Mason <ma...@us...> wrote:

> I just emailed about this. I think this is not a good idea (just try
> running DBT-1 without any distribution clauses). I recommend backing
> this out
>
> Mason
>
>
> ---------- Forwarded message ----------
> From: Michael Paquier <mic...@us...>
> Date: Mon, Mar 7, 2011 at 2:15 AM
> Subject: [Postgres-xc-committers] Postgres-XC branch,
> merge_postgres_9_0_3, updated. v0.9.3-65-gfa427af
> To: pos...@li...
>
>
> Project "Postgres-XC".
>
> The branch, merge_postgres_9_0_3 has been updated
>       via  fa427af446193741501c72e6e026ac493a125137 (commit)
>       via  a6a956e4d1303161750161c0629adb1b4514d345 (commit)
>       via  33342d8d44bb2c36239712d9e7318df0776ce018 (commit)
>      from  9ecde28ad6b6ed00b7588928480bf0bd8a741421 (commit)
>
>
> - Log -----------------------------------------------------------------
> commit fa427af446193741501c72e6e026ac493a125137
> Author: Michael P <mic...@us...>
> Date:   Mon Mar 7 16:09:54 2011 +0900
>
>    CREATE TABLE default distribution to REPLICATED
>
>    Change distribution type of table to REPLICATED when no
>    distribution is specified like with:
>    CREATE TABLE aa (int a);
>
> diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
> index 59231a8..ea20e66 100644
> --- a/src/backend/catalog/heap.c
> +++ b/src/backend/catalog/heap.c
> @@ -874,34 +874,17 @@ AddRelationDistribution (Oid relid,
>                                                 errmsg("Invalid parent
> table distribution type")));
>                                        break;
>                        }
> -               } else
> +               }
> +               else
>                {
>                        /*
>                         * If no distribution was specified, and we
> have not chosen
> -                        * one based on primary key or foreign key,
> use first column with
> -                        * a supported data type.
> +                        * distribute table by replication.
>                         */
> -                       Form_pg_attribute attr;
> -                       int i;
> -
> -                       locatortype = LOCATOR_TYPE_HASH;
> -
> -                       for (i = 0; i < descriptor->natts; i++)
> -                       {
> -                               attr = descriptor->attrs[i];
> -                               if (IsHashDistributable(attr->atttypid))
> -                               {
> -                                       /* distribute on this column */
> -                                       attnum = i + 1;
> -                                       break;
> -                               }
> -                       }
> -
> -                       /* If we did not find a usable type, fall back
> to round robin */
> -                       if (attnum == 0)
> -                               locatortype = LOCATOR_TYPE_RROBIN;
> +                       locatortype = LOCATOR_TYPE_REPLICATED;
>                }
> -       } else
> +       }
> +       else
>        {
>                /*
>                 * User specified distribution type
>
> commit a6a956e4d1303161750161c0629adb1b4514d345
> Author: Michael P <mic...@us...>
> Date:   Mon Mar 7 16:00:16 2011 +0900
>
>    Block PREPARE and EXECUTE for the time being
>
>    It has been noticed that PREPARE crashed the server in some pg_regress
>    test cases.
>
> diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
> index 1240614..bf122db 100644
> --- a/src/backend/tcop/utility.c
> +++ b/src/backend/tcop/utility.c
> @@ -804,11 +804,21 @@ standard_ProcessUtility(Node *parsetree,
>                        break;
>
>                case T_PrepareStmt:
> +#ifdef PGXC
> +                       ereport(ERROR,
> +
> (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> +                                        errmsg("PREPARE is not
> supported")));
> +#endif
>                        CheckRestrictedOperation("PREPARE");
>                        PrepareQuery((PrepareStmt *) parsetree,
> queryString);
>                        break;
>
>                case T_ExecuteStmt:
> +#ifdef PGXC
> +                       ereport(ERROR,
> +
> (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> +                                        errmsg("EXECUTE is not
> supported")));
> +#endif
>                        ExecuteQuery((ExecuteStmt *) parsetree,
> queryString, params,
>                                                 dest, completionTag);
>                        break;
>
> commit 33342d8d44bb2c36239712d9e7318df0776ce018
> Author: Michael P <mic...@us...>
> Date:   Mon Mar 7 15:58:13 2011 +0900
>
>    Fix for CREATE INDEX CONCURRENTLY
>
>    When an index is created concurrently, Coordinator tried to take
>    a snapshot that had already been deleted.
>    We need to take a new one from Coordinator.
>
>    Patch written by Abbas Butt
>
> diff --git a/src/backend/utils/time/snapmgr.c
> b/src/backend/utils/time/snapmgr.c
> index a735fc3..8140321 100644
> --- a/src/backend/utils/time/snapmgr.c
> +++ b/src/backend/utils/time/snapmgr.c
> @@ -34,7 +34,9 @@
>  #include "utils/resowner.h"
>  #include "utils/snapmgr.h"
>  #include "utils/tqual.h"
> -
> +#ifdef PGXC
> +#include "pgxc/pgxc.h"
> +#endif
>
>  /*
>  * CurrentSnapshot points to the only snapshot taken in a serializable
> @@ -344,6 +346,14 @@ PopActiveSnapshot(void)
>  Snapshot
>  GetActiveSnapshot(void)
>  {
> +#ifdef PGXC
> +       /*
> +        * Check if topmost snapshot is null or not,
> +        * if it is, a new one will be taken from GTM.
> +        */
> +       if (!ActiveSnapshot && IS_PGXC_COORDINATOR && !IsConnFromCoord())
> +               return NULL;
> +#endif
>        Assert(ActiveSnapshot != NULL);
>
>        return ActiveSnapshot->as_snap;
>
> -----------------------------------------------------------------------
>
> Summary of changes:
>  src/backend/catalog/heap.c       |   29 ++++++-----------------------
>  src/backend/tcop/utility.c       |   10 ++++++++++
>  src/backend/utils/time/snapmgr.c |   12 +++++++++++-
>  3 files changed, 27 insertions(+), 24 deletions(-)
>
>
> hooks/post-receive
> --
> Postgres-XC
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Postgres-xc-committers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-committers
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>



-- 
Michael Paquier
http://michael.otacoo.com

I just emailed about this. I think this is not a good idea (just try
running DBT-1 without any distribution clauses). I recommend backing
this out

Mason


---------- Forwarded message ----------
From: Michael Paquier <mic...@us...>
Date: Mon, Mar 7, 2011 at 2:15 AM
Subject: [Postgres-xc-committers] Postgres-XC branch,
merge_postgres_9_0_3, updated. v0.9.3-65-gfa427af
To: pos...@li...


Project "Postgres-XC".

The branch, merge_postgres_9_0_3 has been updated
      via  fa427af446193741501c72e6e026ac493a125137 (commit)
      via  a6a956e4d1303161750161c0629adb1b4514d345 (commit)
      via  33342d8d44bb2c36239712d9e7318df0776ce018 (commit)
     from  9ecde28ad6b6ed00b7588928480bf0bd8a741421 (commit)


- Log -----------------------------------------------------------------
commit fa427af446193741501c72e6e026ac493a125137
Author: Michael P <mic...@us...>
Date:   Mon Mar 7 16:09:54 2011 +0900

   CREATE TABLE default distribution to REPLICATED

   Change distribution type of table to REPLICATED when no
   distribution is specified like with:
   CREATE TABLE aa (int a);

diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
index 59231a8..ea20e66 100644
--- a/src/backend/catalog/heap.c
+++ b/src/backend/catalog/heap.c
@@ -874,34 +874,17 @@ AddRelationDistribution (Oid relid,
                                                errmsg("Invalid parent
table distribution type")));
                                       break;
                       }
-               } else
+               }
+               else
               {
                       /*
                        * If no distribution was specified, and we
have not chosen
-                        * one based on primary key or foreign key,
use first column with
-                        * a supported data type.
+                        * distribute table by replication.
                        */
-                       Form_pg_attribute attr;
-                       int i;
-
-                       locatortype = LOCATOR_TYPE_HASH;
-
-                       for (i = 0; i < descriptor->natts; i++)
-                       {
-                               attr = descriptor->attrs[i];
-                               if (IsHashDistributable(attr->atttypid))
-                               {
-                                       /* distribute on this column */
-                                       attnum = i + 1;
-                                       break;
-                               }
-                       }
-
-                       /* If we did not find a usable type, fall back
to round robin */
-                       if (attnum == 0)
-                               locatortype = LOCATOR_TYPE_RROBIN;
+                       locatortype = LOCATOR_TYPE_REPLICATED;
               }
-       } else
+       }
+       else
       {
               /*
                * User specified distribution type

commit a6a956e4d1303161750161c0629adb1b4514d345
Author: Michael P <mic...@us...>
Date:   Mon Mar 7 16:00:16 2011 +0900

   Block PREPARE and EXECUTE for the time being

   It has been noticed that PREPARE crashed the server in some pg_regress
   test cases.

diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
index 1240614..bf122db 100644
--- a/src/backend/tcop/utility.c
+++ b/src/backend/tcop/utility.c
@@ -804,11 +804,21 @@ standard_ProcessUtility(Node *parsetree,
                       break;

               case T_PrepareStmt:
+#ifdef PGXC
+                       ereport(ERROR,
+                                       (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+                                        errmsg("PREPARE is not supported")));
+#endif
                       CheckRestrictedOperation("PREPARE");
                       PrepareQuery((PrepareStmt *) parsetree, queryString);
                       break;

               case T_ExecuteStmt:
+#ifdef PGXC
+                       ereport(ERROR,
+                                       (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+                                        errmsg("EXECUTE is not supported")));
+#endif
                       ExecuteQuery((ExecuteStmt *) parsetree,
queryString, params,
                                                dest, completionTag);
                       break;

commit 33342d8d44bb2c36239712d9e7318df0776ce018
Author: Michael P <mic...@us...>
Date:   Mon Mar 7 15:58:13 2011 +0900

   Fix for CREATE INDEX CONCURRENTLY

   When an index is created concurrently, Coordinator tried to take
   a snapshot that had already been deleted.
   We need to take a new one from Coordinator.

   Patch written by Abbas Butt

diff --git a/src/backend/utils/time/snapmgr.c b/src/backend/utils/time/snapmgr.c
index a735fc3..8140321 100644
--- a/src/backend/utils/time/snapmgr.c
+++ b/src/backend/utils/time/snapmgr.c
@@ -34,7 +34,9 @@
 #include "utils/resowner.h"
 #include "utils/snapmgr.h"
 #include "utils/tqual.h"
-
+#ifdef PGXC
+#include "pgxc/pgxc.h"
+#endif

 /*
 * CurrentSnapshot points to the only snapshot taken in a serializable
@@ -344,6 +346,14 @@ PopActiveSnapshot(void)
 Snapshot
 GetActiveSnapshot(void)
 {
+#ifdef PGXC
+       /*
+        * Check if topmost snapshot is null or not,
+        * if it is, a new one will be taken from GTM.
+        */
+       if (!ActiveSnapshot && IS_PGXC_COORDINATOR && !IsConnFromCoord())
+               return NULL;
+#endif
       Assert(ActiveSnapshot != NULL);

       return ActiveSnapshot->as_snap;

-----------------------------------------------------------------------

Summary of changes:
 src/backend/catalog/heap.c       |   29 ++++++-----------------------
 src/backend/tcop/utility.c       |   10 ++++++++++
 src/backend/utils/time/snapmgr.c |   12 +++++++++++-
 3 files changed, 27 insertions(+), 24 deletions(-)


hooks/post-receive
--
Postgres-XC

------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
Postgres-xc-committers mailing list
Pos...@li...
https://lists.sourceforge.net/lists/listinfo/postgres-xc-committers

Michael,

Actually in CREATE TABLE column data types are analyzed, and if data type is
suitable for the hash function (currently int2, int4, int8) the distribution
type is set to HASH and the found column becomes a distribution key. If no
column with suitable data type is found the distribution type is set to
ROUND ROBIN.
In general, table distribution is a part of database design, like
referential integrity. It is impossible to assign good distribution
automatically.
However having REPLICATED as a default distribution probably is not a good
idea. Table partitioning is a source of performance improvement. Vanilla
Postgres performs better then XC cluster with only replicated tables, and
each XC data node consume more of disk storage and other resources then
single Postgres server. That may disappoint users who have just started XC
evaluation.

2011/3/7 Michael Paquier <mic...@gm...>

> On Mon, Mar 7, 2011 at 1:47 PM, Koichi Suzuki <koi...@gm...>wrote:
>
>> +1
>>
>> Round-robin is not for usual case.   Without distribution
>> specification, replication sounds easier to understand and acceptable.
>> ----------
>> Koichi Suzuki
>>
> Thanks.
> I think this can make regression tests going smoother.
> --
> Michael Paquier
> http://michael.otacoo.com
>
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


-- 
Best regards,
Andrei Martsinchyk                   mailto:and...@gm...

On Mon, Mar 7, 2011 at 1:47 PM, Koichi Suzuki <koi...@gm...> wrote:

> +1
>
> Round-robin is not for usual case.   Without distribution
> specification, replication sounds easier to understand and acceptable.
> ----------
> Koichi Suzuki
>
Thanks.
I think this can make regression tests going smoother.
-- 
Michael Paquier
http://michael.otacoo.com

+1

Round-robin is not for usual case.   Without distribution
specification, replication sounds easier to understand and acceptable.
----------
Koichi Suzuki



2011/3/7 Michael Paquier <mic...@gm...>:
> Hi all,
>
> I wanted to hear some feedback about an idea I had.
> Now the default distribution done when creating a table is ROUND ROBIN.
> This is classified in pgxc_class with a locator type H.
>
> If XC is being used with an application whose DDL cannot be changed,
> or to help with better integration with other applications,
> what do you think if the default distribution of a table is changed from
> round robin to replication?
>
> I believe this would help applications using a low number of datanodes.
>
> Regards,
> --
> Michael Paquier
> http://michael.otacoo.com
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>