postgres-xc-developers Mailing List for Postgres-XC

2012/7/16 Ashutosh Bapat <ash...@en...>:
> Finally I got off reviewing this patch.
>
> One of the problems, with this patch is extensibility. At some point in
> future (and probably very near future), we should allow adding column (an
> example) and redistribution to be done at the same time, to reduce the total
> time of doing ALTER TABLE if it comes to adding column (an example) and
> redistribute the table at the same time. Basically we should allow all the
> table rewriting to be done at the same time as the PostgreSQL ALTER TABLE
> allows to do. The method used here does not leave a room for such combined
> operation, as an extension in future. This means, that when it comes to
> supporting the above said capability we have to rewrite the whole thing
> (leaving may be transformation and node manipulation aside). That's why, I
> would like to see a fix in ATRewriteTable, where we have sequence for every
> row 1 get row, 2. rewrite the row 3. write the new row.


I'm afraid this is too much for the current work.   In the last core
team meeting, we agreed not to include general ALTER TABLE feature in
CONCURRENT operation.     Although I think it's better to have such
extension ready in the current feature, we have much more carried over
beyond 2.0, it's also important to have features really work.

>
> Anyway, I have following comments for the patch itself,
> 1. Need better name for PgxcClassAlter().

Any idea?

> 2. In ATController, why do you need to move ATCheckCmd below ATPrepCmd?
> 3. Comments on line 2933 and 2941 can be worded as "Perform
> pre-catalog-update redistribution operations" and "Perform
> post-catalog-update redistribution operations"
> 4. Why can't redistribution be run in a transaction block? Does the
> redistribution run as a transaction? What happens if the server crashes
> while redistribution is being done at various stages of its progress?

Hmm, this could be some limitation.   PostgreSQL's ALTER TABLE, unlike
MySQL and older version of Oracle, can run in a transaction block and
most users would like this feature too.

> 5. Do you want to rename BuildDistribCommands() as BuildReDistribCommands()?
> 6. In function BuildDistribCommands(), What does variable new_oids signify?
> I think it's signifying the new node oids, if so please use name
> accordingly.
> 7. The names of function tree_build_entry() and its minions look pretty
> generic, we need some prefix to these functions like pgxc_redist_ or
> something like that. BTW, what's the "tree" there indicate? There is nothing
> like tree that is being built, it's just a list of commands.
> 8. Why are you using repalloc in tree_add_single_command(), you can rather
> create a list and append to that list.
> 9. We don't need two separate functions Pre and Post - Update(), it can be a
> single function which takes the Pre/Post as flag and runs the relevant
> commands. BTW, just PreUpdate does not show its real meaning, it should be
> something like PreCatalogUpdate() or something like that.
> 10. Why every catalog change to pgxc_class invalidates the cache? We should
> do it only once for a given command.
> 11. The functions add_oid_list, delete_oid_list etc. are using oid arrays,
> then why use the suffice _list() in those functions? I do not like the
> frequence repalloc that happens in both these functions. Worst is the
> movement of array element in delete_node_list(). Any mistake here would be
> disastrous. PostgreSQL code is very generous in using memory to keep things
> simple. You can use lists or bitmaps if you want to save the space, but not
> repalloc.
> 12. Instead of a single file distrib directory, you can use locator
> directory with distrib.c file (better if you could use name like at_distrib
> or redistrib, since the files really belong to ALTER TABLE?
> 13. In makeRemoteCopyOptions you are using palloc0(), which sets all the
> memory with 0, so bools automatically get value false and NULL lists as NIL,
> you don't need to set those explicitly.
> 14. I do not see any tests related to sanity of views, rules and other
> objects which depend upon the table, after the table is redistributed using
> this method. May be it's a good idea to provide a prologue at the beginning
> of the testcase specifying how the testcase is laid out.
>
>
> On Mon, Jul 16, 2012 at 4:56 PM, Ashutosh Bapat
> <ash...@en...> wrote:
>>
>>
>>> In this case you do not need any code! You could also do a simple CREATE
>>> TABLE AS to redistribution the table as you wish to a new table, drop the
>>> old table, and rename the new table with the old name. This could also be
>>> done with 1.0.
>>> You should also have a look at my latest patch, it already includes the
>>> maximum optimizations possible for replicated table redistribution,
>>> particularly distrib.c. Just by looking at that you will see that a node
>>> level control is more than necessary.
>>
>>
>> This method would change the OID of the table and thus invalidate all the
>> view definitions, rules etc. depending on this table. We don't want that to
>> happen. The function would not change the OID, but would write the data in
>> the table's space itself.
>>
>>>
>>> --
>>> Michael Paquier
>>> http://michael.otacoo.com
>>
>>
>>
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>> EntepriseDB Corporation
>> The Enterprise Postgres Company
>>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

Finally I got off reviewing this patch.

One of the problems, with this patch is extensibility. At some point in
future (and probably very near future), we should allow adding column (an
example) and redistribution to be done at the same time, to reduce the
total time of doing ALTER TABLE if it comes to adding column (an example)
and redistribute the table at the same time. Basically we should allow all
the table rewriting to be done at the same time as the PostgreSQL ALTER
TABLE allows to do. The method used here does not leave a room for such
combined operation, as an extension in future. This means, that when it
comes to supporting the above said capability we have to rewrite the whole
thing (leaving may be transformation and node manipulation aside). That's
why, I would like to see a fix in ATRewriteTable, where we have sequence
for every row 1 get row, 2. rewrite the row 3. write the new row.

Anyway, I have following comments for the patch itself,
1. Need better name for PgxcClassAlter().
2. In ATController, why do you need to move ATCheckCmd below ATPrepCmd?
3. Comments on line 2933 and 2941 can be worded as "Perform
pre-catalog-update redistribution operations" and "Perform
post-catalog-update redistribution operations"
4. Why can't redistribution be run in a transaction block? Does the
redistribution run as a transaction? What happens if the server crashes
while redistribution is being done at various stages of its progress?
5. Do you want to rename BuildDistribCommands() as BuildReDistribCommands()?
6. In function BuildDistribCommands(), What does variable new_oids signify?
I think it's signifying the new node oids, if so please use name
accordingly.
7. The names of function tree_build_entry() and its minions look pretty
generic, we need some prefix to these functions like pgxc_redist_ or
something like that. BTW, what's the "tree" there indicate? There is
nothing like tree that is being built, it's just a list of commands.
8. Why are you using repalloc in tree_add_single_command(), you can rather
create a list and append to that list.
9. We don't need two separate functions Pre and Post - Update(), it can be
a single function which takes the Pre/Post as flag and runs the relevant
commands. BTW, just PreUpdate does not show its real meaning, it should be
something like PreCatalogUpdate() or something like that.
10. Why every catalog change to pgxc_class invalidates the cache? We should
do it only once for a given command.
11. The functions add_oid_list, delete_oid_list etc. are using oid arrays,
then why use the suffice _list() in those functions? I do not like the
frequence repalloc that happens in both these functions. Worst is the
movement of array element in delete_node_list(). Any mistake here would be
disastrous. PostgreSQL code is very generous in using memory to keep things
simple. You can use lists or bitmaps if you want to save the space, but not
repalloc.
12. Instead of a single file distrib directory, you can use locator
directory with distrib.c file (better if you could use name like at_distrib
or redistrib, since the files really belong to ALTER TABLE?
13. In makeRemoteCopyOptions you are using palloc0(), which sets all the
memory with 0, so bools automatically get value false and NULL lists as
NIL, you don't need to set those explicitly.
14. I do not see any tests related to sanity of views, rules and other
objects which depend upon the table, after the table is redistributed using
this method. May be it's a good idea to provide a prologue at the beginning
of the testcase specifying how the testcase is laid out.

On Mon, Jul 16, 2012 at 4:56 PM, Ashutosh Bapat <
ash...@en...> wrote:

>
> In this case you do not need any code! You could also do a simple CREATE
>> TABLE AS to redistribution the table as you wish to a new table, drop the
>> old table, and rename the new table with the old name. This could also be
>> done with 1.0.
>> You should also have a look at my latest patch, it already includes the
>> maximum optimizations possible for replicated table redistribution,
>> particularly distrib.c. Just by looking at that you will see that a node
>> level control is more than necessary.
>>
>
> This method would change the OID of the table and thus invalidate all the
> view definitions, rules etc. depending on this table. We don't want that to
> happen. The function would not change the OID, but would write the data in
> the table's space itself.
>
>
>> --
>> Michael Paquier
>> http://michael.otacoo.com
>>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>
>


-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company

> In this case you do not need any code! You could also do a simple CREATE
> TABLE AS to redistribution the table as you wish to a new table, drop the
> old table, and rename the new table with the old name. This could also be
> done with 1.0.
> You should also have a look at my latest patch, it already includes the
> maximum optimizations possible for replicated table redistribution,
> particularly distrib.c. Just by looking at that you will see that a node
> level control is more than necessary.
>

This method would change the OID of the table and thus invalidate all the
view definitions, rules etc. depending on this table. We don't want that to
happen. The function would not change the OID, but would write the data in
the table's space itself.


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



-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company

On Mon, Jul 16, 2012 at 3:25 PM, Ashutosh Bapat <
ash...@en...> wrote:

>
>
>> Honestly I thought about such solutions before beginning my stuff, but
>> arrived at the conclusion that we need a native way to manage
>> redistribution. In this case, you fall under the following limitations:
>> - How to manage node-level granularity for redistribution operations? In
>> XC, by design, a SQL is launched globally on the cluster. At the exception
>> of EXECUTE DIRECT but it only allows SELECT commands.
>>
>
> Under some conditions (using a GUC, say) we may allow having TRUNCATE to
> be executed as part of EXECUTE DIRECT, if it becomes necessary. But we may
> have problems related to permissions. See below.
>
That is why is it really necessary to


>
>
>> - When and how to manage the catalog update? Even if it is possible to
>> update catalog with DMLs, we need native APIs to be able to modify catalog
>> entries.
>>
>
> We can update catalogs using simple catalog updates, and such updates are
> transactionally safe. I verified that. (See my patch on separate thread).
>
Yes they are, but manipulating catalogs with DML is not postgreSQL-like, as
usually catalog update has as consequences to make other internal
operations like dependencies, permission checks and cache invalidation.


>
>
>> - CREATE NODE is used for the addition and deletion of nodes. Data
>> redistribution does not concern changing the configuration of the cluster.
>> You got a certain number of Datanodes, Coordinators, and you want to change
>> the nodes where data of a table is located inside this given cluster. Your
>> approach makes redistribution dependent on cluster configuration and it is
>> honestly not welcome to add such degrees of dependencies that may be a
>> burden in the future if we change once again the way cluster is configured.
>>
>
> Probably Nikhil misunderstood intent of CREATE NODE. CREATE NODE has
> nothing to do with redistribution.
>
Yes, think so.

>
>
>>  - For certain redistribution operations, we do NOT always need a
>> transaction block! Just take the example of a replicated table changed to a
>> distributed table. You just need to send a DELETE query to remote nodes to
>> remove only the tuples that do not satisfy a hash condition. This is one of
>> those things I am working on now.
>>
>
> We will need transaction block to make the utility transactionally safe.
>

>> To my mind, each argument here makes necessary this feature in core. All
>> combined even strengthen my arguments.
>>
>>
> I am not able to answer still serious problems -
> 1. Checking permissions to allow such a function to be run. Should we
> allow anyone who can run those DDLs/DMLs run the utility?
>
Only the owner of the table. But this needs to be controlled internally. We
may have serious security issues lying under that.


> 2. Cache invalidation - how do we invalidate plan caches after
> redistributing the data? Plan stores the list of nodes where the queries
> should be executed. Storing this list of nodes in plans is essential from
> JOIN reduction.
>
Yes, and for a couple of other things. You will need to add externally some
runs of DEALLOCATE ALL, but this will impact all tables and not only the
one being redistributed. My latest patch only invalidated cache of the
table involved by redistribution.


>
> Are there answers to these questions?
>
> But this approach has some merits - 1. It reduces the impact on the code.
>
Yes, but redistribution needs to be a core operation.


> 2. There are few things not so good in this approach, like disk and
> network usage, which needs to be optimized. By taking this approach, we
> provide an easy (albeit unoptimised) way of re-distributing the tables and
> can work on the final version of code changes for ALTER TABLE DISTRIBUTE
> afterwards, keeping longer slot for the work.
>
In this case you do not need any code! You could also do a simple CREATE
TABLE AS to redistribution the table as you wish to a new table, drop the
old table, and rename the new table with the old name. This could also be
done with 1.0.
You should also have a look at my latest patch, it already includes the
maximum optimizations possible for replicated table redistribution,
particularly distrib.c. Just by looking at that you will see that a node
level control is more than necessary.
-- 
Michael Paquier
http://michael.otacoo.com

> Honestly I thought about such solutions before beginning my stuff, but
> arrived at the conclusion that we need a native way to manage
> redistribution. In this case, you fall under the following limitations:
> - How to manage node-level granularity for redistribution operations? In
> XC, by design, a SQL is launched globally on the cluster. At the exception
> of EXECUTE DIRECT but it only allows SELECT commands.
>

Under some conditions (using a GUC, say) we may allow having TRUNCATE to be
executed as part of EXECUTE DIRECT, if it becomes necessary. But we may
have problems related to permissions. See below.


> - When and how to manage the catalog update? Even if it is possible to
> update catalog with DMLs, we need native APIs to be able to modify catalog
> entries.
>

We can update catalogs using simple catalog updates, and such updates are
transactionally safe. I verified that. (See my patch on separate thread).


> - CREATE NODE is used for the addition and deletion of nodes. Data
> redistribution does not concern changing the configuration of the cluster.
> You got a certain number of Datanodes, Coordinators, and you want to change
> the nodes where data of a table is located inside this given cluster. Your
> approach makes redistribution dependent on cluster configuration and it is
> honestly not welcome to add such degrees of dependencies that may be a
> burden in the future if we change once again the way cluster is configured.
>

Probably Nikhil misunderstood intent of CREATE NODE. CREATE NODE has
nothing to do with redistribution.


> - For certain redistribution operations, we do NOT always need a
> transaction block! Just take the example of a replicated table changed to a
> distributed table. You just need to send a DELETE query to remote nodes to
> remove only the tuples that do not satisfy a hash condition. This is one of
> those things I am working on now.
>

We will need transaction block to make the utility transactionally safe.


>
> To my mind, each argument here makes necessary this feature in core. All
> combined even strengthen my arguments.
>
>
I am not able to answer still serious problems -
1. Checking permissions to allow such a function to be run. Should we allow
anyone who can run those DDLs/DMLs run the utility?
2. Cache invalidation - how do we invalidate plan caches after
redistributing the data? Plan stores the list of nodes where the queries
should be executed. Storing this list of nodes in plans is essential from
JOIN reduction.

Are there answers to these questions?

But this approach has some merits - 1. It reduces the impact on the code.
2. There are few things not so good in this approach, like disk and network
usage, which needs to be optimized. By taking this approach, we provide an
easy (albeit unoptimised) way of re-distributing the tables and can work on
the final version of code changes for ALTER TABLE DISTRIBUTE afterwards,
keeping longer slot for the work.


>
>> Regards,
>> Nikhils
>>
>> > Something I am afraid is not possible with an external utility is
>> control of
>> > redistribution at node level. For example, an external contrib module or
>> > utility will launch SQL queries to xc that have to be treated as global.
>> > However, redistribution needs to take care of cases like for example the
>> > reduction of nodes for replicated tables. In this case you just need to
>> > delete the data from removed nodes. Another easy example is the case of
>> an
>> > increase of nodes for replicated tables. You need to pick up data on
>> > coordinator and then send it only to the new nodes. Those simple
>> examples
>> > need a core management to minimize the work of redistribution inside
>> > cluster.
>> >
>> > On 2012/07/13, at 15:09, Ashutosh Bapat <
>> ash...@en...>
>> > wrote:
>> >
>> > Even, I am wondering if that would be better.
>> >
>> > But, one thing that is essential is catalog updates. Are you suggesting
>> that
>> > the catalog updates too should be done using some SQL?
>> >
>> > Can you please expand more on your idea, may be providing some examples,
>> > pseudo-code etc.?
>> >
>> > On Fri, Jul 13, 2012 at 10:36 AM, Nikhil Sontakke <ni...@st...>
>> > wrote:
>> >>
>> >> Just a thought.
>> >>
>> >> If we have a utility which spews out all of these statements to
>> >> redistribute a table across node modifications, then we can just wrap
>> >> them inside a transaction block and just run that?
>> >>
>> >> Wont it save all of the core changes?
>> >>
>> >> Regards,
>> >> Nikhils
>> >>
>> >> On Fri, Jul 13, 2012 at 12:29 AM, Michael Paquier
>> >> <mic...@gm...> wrote:
>> >> > Hi all,
>> >> >
>> >> > Please find attached an updated patch adding redistribution
>> >> > optimizations
>> >> > for replicated tables.
>> >> > If the node subset of a replicated table is reduced, the necessary
>> nodes
>> >> > are
>> >> > simply truncated.
>> >> > If it is increased, a COPY TO is done to fetch the data, and COPY
>> FROM
>> >> > is
>> >> > done only on the necessary nodes.
>> >> > New regression tests have been added to test that.
>> >> >
>> >> > Regards,
>> >> >
>> >> >
>> >> > On Thu, Jul 12, 2012 at 5:30 PM, Michael Paquier
>> >> > <mic...@gm...>
>> >> > wrote:
>> >> >>
>> >> >> OK, here is the mammoth patch: 3000 lines including docs,
>> >> >> implementation
>> >> >> and  regressions.
>> >> >> The code has been realigned with current master.
>> >> >> This patch introduces the latest thing I am working on: the
>> >> >> redistribution
>> >> >> command tree planning and execution.
>> >> >>
>> >> >> As I explained before, a redistribution consists of a series of
>> >> >> commands
>> >> >> (TRUNCATE, REINDEX, DELETE, COPY FROM, COPY TO) that need to be
>> >> >> determined
>> >> >> depending on the new and old locator information of the relation.
>> Each
>> >> >> action can be done on a subset of nodes.
>> >> >> This patch introduces the basic infrastructure of the command tree
>> >> >> build
>> >> >> and execution.
>> >> >> For the time being, redistribution uses only what is called the
>> default
>> >> >> command tree consisting of:
>> >> >> 1) COPY TO
>> >> >> 2) TRUNCATE
>> >> >> 3) COPY FROM
>> >> >> 4) REINDEX
>> >> >> But this structure can be easily completed with more complicated
>> >> >> operations.
>> >> >> In this patch there is still a small thing missing which is the
>> >> >> possibility to launch a COPY FROM on a subset of nodes, particularly
>> >> >> useful
>> >> >> when redistribution consists of a replicated table whose set of
>> nodes
>> >> >> is
>> >> >> increased.
>> >> >> Compared to the last versions, the impact of redistribution in
>> >> >> tablecmds.c
>> >> >> is limited.
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> --
>> >> >> Michael Paquier
>> >> >> http://michael.otacoo.com
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Michael Paquier
>> >> > http://michael.otacoo.com
>> >> >
>> >> >
>> >> >
>> ------------------------------------------------------------------------------
>> >> > Live Security Virtual Conference
>> >> > Exclusive live event will cover all the ways today's security and
>> >> > threat landscape has changed and how IT managers can respond.
>> >> > Discussions
>> >> > will include endpoint security, mobile security and the latest in
>> >> > malware
>> >> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> >> > _______________________________________________
>> >> > Postgres-xc-developers mailing list
>> >> > Pos...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> StormDB - http://www.stormdb.com
>> >> The Database Cloud
>> >
>> >
>> >
>> >
>> > --
>> > Best Wishes,
>> > Ashutosh Bapat
>> > EntepriseDB Corporation
>> > The Enterprise Postgres Company
>> >
>>
>>
>>
>> --
>> StormDB - http://www.stormdb.com
>> The Database Cloud
>>
>
>
>
> --
> Michael Paquier
> http://michael.otacoo.com
>



-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company

Here make check works correctly with CentOS 5.X, Ubuntu and ArchLinux.
You should have a look at each node's log file in src/test/regress/log/ to
find what is happening.
-- 
Michael Paquier
http://michael.otacoo.com

It looks like you are not at the beach today, based in Ibaraki? :)


On Mon, Jul 16, 2012 at 2:18 PM, <hir...@hi...> wrote:

>
> Hi. Develoers.
>
> In the environment using gtm_proxy, in order that error may come out,
> please let me know the vital point of correction.
> (when not using gtm_proxy ( = When accessing direct to gtm ), error does
> not come out.)
>
> [ server's composition]
> Node1(oss240g1): coord1, datanode1, gtm_proxy1
> Node2(oss240g2): coord2, datanode2, gtm_proxy2
> Node3(oss240g3): gtm and Operation of pgbench
>
> [oss240g3 pgbench operation]
> [pgxc@oss240g3 co2dn2]$ pgbench  -n -c 13 test1 -h oss240g1
> Client 2 aborted in state 12: ERROR:  GTM error, could not obtain snapshot
> Client 3 aborted in state 10: ERROR:  GTM error, could not obtain snapshot
> Client 9 aborted in state 11: ERROR:  GTM error, could not obtain snapshot
> transaction type: TPC-B (sort of)
> scaling factor: 10
> query mode: simple
> number of clients: 13
> number of threads: 1
> number of transactions per client: 10
> number of transactions actually processed: 126/130
> tps = ....
>
> [gtm's log]
> 1:140678569928448:2012-07-15 17:31:38.641 JST -LOG:  Any GTM standby node
> not found in registered node(s).
> LOCATION:  gtm_standby_connect_to_standby_int, gtm_standby.c:376
> 1:140678569920256:2012-07-15 17:31:38.645 JST -LOG:
>  ProcessPGXCNodeRegister: ipaddress = "localhost", node name =
> "gtm_proxy1", proxy name = "", datafolder "/data/pgxc/co2dn2/gtm_proxy1"
> LOCATION:  ProcessPGXCNodeRegister, register_gtm.c:99
> 1:140678569920256:2012-07-15 17:31:38.645 JST -LOG:  Node type = 1
> LOCATION:  ProcessPGXCNodeRegister, register_gtm.c:116
> 1:140678569920256:2012-07-15 17:31:38.646 JST -LOG:
>  Recovery_PGXCNodeRegister Request info: type=1, nodename=gtm_proxy1,
> port=6666,datafolder=/data/pgxc/co2dn2/gtm_proxy1, ipaddress=localhost,
> status=0
> LOCATION:  Recovery_PGXCNodeRegister, register_common.c:397
> ........
> 1:140678538450688:2012-07-15 17:31:55.063 JST -LOG:  Node type = 1
> LOCATION:  ProcessPGXCNodeRegister, register_gtm.c:116
> 1:140678538450688:2012-07-15 17:31:55.063 JST -LOG:
>  Recovery_PGXCNodeRegister Request info: type=1, nodename=gtm_proxy2,
> port=6666,datafolder=/data/pgxc/co2dn2/gtm_proxy2, ipaddress=localhost,
> status=0
> LOCATION:  Recovery_PGXCNodeRegister, register_common.c:397
> 1:140678538450688:2012-07-15 17:31:55.063 JST -LOG:
>  Recovery_PGXCNodeRegister Node info: type=1, nodename=gtm_proxy2,
> port=6666, datafolder=/data/pgxc/co2dn2/gtm_proxy2, ipaddress=localhost,
> status=0
> LOCATION:  Recovery_PGXCNodeRegister, register_common.c:400
> 1:140678569928448:2012-07-15 17:31:55.080 JST -LOG:  Any GTM standby node
> not found in registered node(s).
> ........
> 1:140678548940544:2012-07-15 17:36:57.701 JST -ERROR:  Failed to get a
> snapshot
> LOCATION:  ProcessGetSnapshotCommandMulti, gtm_snap.c:419
> 1:140678559430400:2012-07-15 17:36:57.702 JST -LOG:  Sending transaction
> ids from 20734 to 20735
> LOCATION:  ProcessBeginTransactionGetGXIDCommandMulti, gtm_txn.c:1463
> 1:140678559430400:2012-07-15 17:36:57.720 JST -LOG:  Committing: prepared
> id 20721 and commit prepared id 20733
> LOCATION:  ProcessCommitPreparedTransactionCommand, gtm_txn.c:1697
> 1:140678548940544:2012-07-15 17:36:57.722 JST -WARNING:  Invalid
> transaction handle: -1
> LOCATION:  GTM_HandleToTransactionInfo, gtm_txn.c:206
> 1:140678548940544:2012-07-15 17:36:57.723 JST -ERROR:  Failed to get a
> snapshot
> LOCATION:  ProcessGetSnapshotCommandMulti, gtm_snap.c:419
> 1:140678559430400:2012-07-15 17:36:57.755 JST -LOG:  Committing: prepared
> id 20715 and commit prepared id 20734
> LOCATION:  ProcessCommitPreparedTransactionCommand, gtm_txn.c:1697
> 1:140678548940544:2012-07-15 17:36:57.755 JST -LOG:  Sending transaction
> ids from 20735 to 20736
> LOCATION:  ProcessBeginTransactionGetGXIDCommandMulti, gtm_txn.c:1463
> 1:140678548940544:2012-07-15 17:36:57.771 JST -WARNING:  Invalid
> transaction handle: -1
> LOCATION:  GTM_HandleToTransactionInfo, gtm_txn.c:206
> 1:140678548940544:2012-07-15 17:36:57.771 JST -ERROR:  Failed to get a
> snapshot
> LOCATION:  ProcessGetSnapshotCommandMulti, gtm_snap.c:419
> 1:140678559430400:2012-07-15 17:36:57.772 JST -LOG:  Sending transaction
> ids from 20736 to 20737
>
> [gtm_proxy1's log]
> LOCATION:  GTMProxy_SigleHandler, proxy_main.c:406
> 1:139748173334272:2012-07-15 17:31:37.788 JST -LOG:  Starting GTM proxy at
> (localhost:6666)
> LOCATION:  main, proxy_main.c:838
> 1:139748026468096:2012-07-15 17:36:56.718 JST -ERROR2:  snapshot request
> failed
>
It looks like you got a problem here.
Has anybody seen such errors with GTM-proxy?


> LOCATION:  ProcessResponse, proxy_main.c:1952
> 1:139748026468096:2012-07-15 17:36:56.914 JST -ERROR:  Wrong result
> LOCATION:  ProcessResponse, proxy_main.c:1921
> 1:139748171175680:2012-07-15 17:36:57.004 JST -ERROR2:  Transaction commit
> failed
> LOCATION:  ProcessResponse, proxy_main.c:1910
> 1:139748171175680:2012-07-15 17:37:17.115 JST -ERROR2:  Transaction commit
> failed
> LOCATION:  ProcessResponse, proxy_main.c:1910
>
> [gtm_proxy2s log]
> LOCATION:  GTMProxy_SigleHandler, proxy_main.c:406
> 1:140023358203648:2012-07-15 17:31:55.485 JST -LOG:  Starting GTM proxy at
> (localhost:6666)
>
> [Postgres-XC Version]
> postgtres-xc-postgres-xc-XC1_0_0_PG9_1-27-gd549c2f.zip
>
looks like more or less the latest code here.
-- 
Michael Paquier
http://michael.otacoo.com

This merge idea looks nice. But I see 2 issues.
1) What is cruelly missing in the current design is the possibility to run
a Postgres-XC node as a GTM-Proxy standalone. This means that this
Postgres-XC node would only proxy messages to GTM and only that. It will
need to reject other client applications.
This would allow cascading of GTM Proxies and more flexibility in the
system.
If you guys are able to add that, well we gain in code maintenance and keep
the same architecture possible.
2) Performance? We will need to test that under really a heavy load before
committing it.
-- 
Michael Paquier
http://michael.otacoo.com

Hi. Develoers.

In the environment using gtm_proxy, in order that error may come out, 
please let me know the vital point of correction.
(when not using gtm_proxy ( = When accessing direct to gtm ), error does not come out.)
  
[ server's composition]
Node1(oss240g1): coord1, datanode1, gtm_proxy1
Node2(oss240g2): coord2, datanode2, gtm_proxy2
Node3(oss240g3): gtm and Operation of pgbench 

[oss240g3 pgbench operation]
[pgxc@oss240g3 co2dn2]$ pgbench  -n -c 13 test1 -h oss240g1
Client 2 aborted in state 12: ERROR:  GTM error, could not obtain snapshot
Client 3 aborted in state 10: ERROR:  GTM error, could not obtain snapshot
Client 9 aborted in state 11: ERROR:  GTM error, could not obtain snapshot
transaction type: TPC-B (sort of)
scaling factor: 10
query mode: simple
number of clients: 13
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 126/130
tps = ....

[gtm's log]
1:140678569928448:2012-07-15 17:31:38.641 JST -LOG:  Any GTM standby node not found in registered node(s).
LOCATION:  gtm_standby_connect_to_standby_int, gtm_standby.c:376
1:140678569920256:2012-07-15 17:31:38.645 JST -LOG:  ProcessPGXCNodeRegister: ipaddress = "localhost", node name = "gtm_proxy1", proxy name = "", datafolder "/data/pgxc/co2dn2/gtm_proxy1"
LOCATION:  ProcessPGXCNodeRegister, register_gtm.c:99
1:140678569920256:2012-07-15 17:31:38.645 JST -LOG:  Node type = 1
LOCATION:  ProcessPGXCNodeRegister, register_gtm.c:116
1:140678569920256:2012-07-15 17:31:38.646 JST -LOG:  Recovery_PGXCNodeRegister Request info: type=1, nodename=gtm_proxy1, port=6666,datafolder=/data/pgxc/co2dn2/gtm_proxy1, ipaddress=localhost, status=0
LOCATION:  Recovery_PGXCNodeRegister, register_common.c:397
........
1:140678538450688:2012-07-15 17:31:55.063 JST -LOG:  Node type = 1
LOCATION:  ProcessPGXCNodeRegister, register_gtm.c:116
1:140678538450688:2012-07-15 17:31:55.063 JST -LOG:  Recovery_PGXCNodeRegister Request info: type=1, nodename=gtm_proxy2, port=6666,datafolder=/data/pgxc/co2dn2/gtm_proxy2, ipaddress=localhost, status=0
LOCATION:  Recovery_PGXCNodeRegister, register_common.c:397
1:140678538450688:2012-07-15 17:31:55.063 JST -LOG:  Recovery_PGXCNodeRegister Node info: type=1, nodename=gtm_proxy2, port=6666, datafolder=/data/pgxc/co2dn2/gtm_proxy2, ipaddress=localhost, status=0
LOCATION:  Recovery_PGXCNodeRegister, register_common.c:400
1:140678569928448:2012-07-15 17:31:55.080 JST -LOG:  Any GTM standby node not found in registered node(s).
........
1:140678548940544:2012-07-15 17:36:57.701 JST -ERROR:  Failed to get a snapshot
LOCATION:  ProcessGetSnapshotCommandMulti, gtm_snap.c:419
1:140678559430400:2012-07-15 17:36:57.702 JST -LOG:  Sending transaction ids from 20734 to 20735
LOCATION:  ProcessBeginTransactionGetGXIDCommandMulti, gtm_txn.c:1463
1:140678559430400:2012-07-15 17:36:57.720 JST -LOG:  Committing: prepared id 20721 and commit prepared id 20733
LOCATION:  ProcessCommitPreparedTransactionCommand, gtm_txn.c:1697
1:140678548940544:2012-07-15 17:36:57.722 JST -WARNING:  Invalid transaction handle: -1
LOCATION:  GTM_HandleToTransactionInfo, gtm_txn.c:206
1:140678548940544:2012-07-15 17:36:57.723 JST -ERROR:  Failed to get a snapshot
LOCATION:  ProcessGetSnapshotCommandMulti, gtm_snap.c:419
1:140678559430400:2012-07-15 17:36:57.755 JST -LOG:  Committing: prepared id 20715 and commit prepared id 20734
LOCATION:  ProcessCommitPreparedTransactionCommand, gtm_txn.c:1697
1:140678548940544:2012-07-15 17:36:57.755 JST -LOG:  Sending transaction ids from 20735 to 20736
LOCATION:  ProcessBeginTransactionGetGXIDCommandMulti, gtm_txn.c:1463
1:140678548940544:2012-07-15 17:36:57.771 JST -WARNING:  Invalid transaction handle: -1
LOCATION:  GTM_HandleToTransactionInfo, gtm_txn.c:206
1:140678548940544:2012-07-15 17:36:57.771 JST -ERROR:  Failed to get a snapshot
LOCATION:  ProcessGetSnapshotCommandMulti, gtm_snap.c:419
1:140678559430400:2012-07-15 17:36:57.772 JST -LOG:  Sending transaction ids from 20736 to 20737

[gtm_proxy1's log]
LOCATION:  GTMProxy_SigleHandler, proxy_main.c:406
1:139748173334272:2012-07-15 17:31:37.788 JST -LOG:  Starting GTM proxy at (localhost:6666)
LOCATION:  main, proxy_main.c:838
1:139748026468096:2012-07-15 17:36:56.718 JST -ERROR2:  snapshot request failed
LOCATION:  ProcessResponse, proxy_main.c:1952
1:139748026468096:2012-07-15 17:36:56.914 JST -ERROR:  Wrong result
LOCATION:  ProcessResponse, proxy_main.c:1921
1:139748171175680:2012-07-15 17:36:57.004 JST -ERROR2:  Transaction commit failed
LOCATION:  ProcessResponse, proxy_main.c:1910
1:139748171175680:2012-07-15 17:37:17.115 JST -ERROR2:  Transaction commit failed
LOCATION:  ProcessResponse, proxy_main.c:1910

[gtm_proxy2s log]
LOCATION:  GTMProxy_SigleHandler, proxy_main.c:406
1:140023358203648:2012-07-15 17:31:55.485 JST -LOG:  Starting GTM proxy at (localhost:6666)

[Postgres-XC Version]
postgtres-xc-postgres-xc-XC1_0_0_PG9_1-27-gd549c2f.zip

As mentioned above, I need your help well. 
----------
Hiroshi Kise
Hitachi, Ltd., IT Platform Division
5030, Totsuka-cyo, Totsuka-ku, Yokohama, 244-8555 Japan
  

This is another reason gtm proxy merge can be done when
coordinator/datanod are integrated into single node.   Anyway, it has
not been decided yet and would need more discussion.

Regards;
----------
Koichi Suzuki


2012/7/16 Ashutosh Bapat <ash...@en...>:
> Does that mean, that every coordinator, datanode runs a GTM-proxy?
>
> In typical XC configuration, we can have datanode and coordinator running on
> same machine/server. For that matter we can have as many nodes running on a
> server as one wants. I think, a GTM-proxy can be shared among them.
>
> On Sat, Jul 14, 2012 at 9:14 AM, Andrei Martsinchyk
> <and...@gm...> wrote:
>>
>> We have an idea to merge GTM Proxy into the XC core and make it an
>> auxiliary process, like pooler, background writer, logger, etc.
>> Like any other auxiliary process it would be started with the node,
>> stopped with the node and serve sessions running under the same postmaster.
>> The session would be always communicate to GTM via internal proxy.
>> Configuration parameters specific to GTM proxy will be moved to the main
>> config file, some of them like GTM host/port are already there, they would
>> be used by the Proxy, session would be connected to the port where it is
>> listening, it would be in the same config file.
>> We see following benefits of doing this:
>> - We force people to connect to GTM via proxy and achieve better
>> performance.
>> - Better maintainability: -1 configuration file, -1 log file, -1 entity to
>> manage and monitor. The proxy would share main configuration log, main log
>> file, and postmaster would monitor proxy and restart if it fails, the
>> housekeeping code is already here.
>> - Effectiveness: having proxy running under the same postmaster as its
>> clients would allow to use faster communication channels, like unix sockets,
>> pipes, shared memory.
>> - Reliability: if main GTM server goes down GTM proxy able to reconnect to
>> a promoted standby, but not session. If session would always connect to the
>> proxy it always would be able to reconnect.
>> The only drawback we see is that the multiple nodes would not be able to
>> share the same proxy.
>> So, any ideas? Is it worth doing? Any pros and cons we are missing?
>>
>> --
>> Andrei Martsinchyk
>>
>> StormDB - http://www.stormdb.com
>> The Database Cloud
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

Does that mean, that every coordinator, datanode runs a GTM-proxy?

In typical XC configuration, we can have datanode and coordinator running
on same machine/server. For that matter we can have as many nodes running
on a server as one wants. I think, a GTM-proxy can be shared among them.

On Sat, Jul 14, 2012 at 9:14 AM, Andrei Martsinchyk <
and...@gm...> wrote:

> We have an idea to merge GTM Proxy into the XC core and make it an
> auxiliary process, like pooler, background writer, logger, etc.
> Like any other auxiliary process it would be started with the node,
> stopped with the node and serve sessions running under the same postmaster.
> The session would be always communicate to GTM via internal proxy.
> Configuration parameters specific to GTM proxy will be moved to the main
> config file, some of them like GTM host/port are already there, they would
> be used by the Proxy, session would be connected to the port where it is
> listening, it would be in the same config file.
> We see following benefits of doing this:
> - We force people to connect to GTM via proxy and achieve better
> performance.
> - Better maintainability: -1 configuration file, -1 log file, -1 entity to
> manage and monitor. The proxy would share main configuration log, main log
> file, and postmaster would monitor proxy and restart if it fails, the
> housekeeping code is already here.
> - Effectiveness: having proxy running under the same postmaster as its
> clients would allow to use faster communication channels, like unix
> sockets, pipes, shared memory.
> - Reliability: if main GTM server goes down GTM proxy able to reconnect to
> a promoted standby, but not session. If session would always connect to the
> proxy it always would be able to reconnect.
> The only drawback we see is that the multiple nodes would not be able to
> share the same proxy.
> So, any ideas? Is it worth doing? Any pros and cons we are missing?
>
> --
> Andrei Martsinchyk
>
> StormDB - http://www.stormdb.com
> The Database Cloud
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company

As we have another idea to merge coordinator and datanode for more
performance gain, I think we could do this merge together.

Current gtm proxy code is based upon gtm and is based upon
multi-thread, it does not fit to coordinator/datanode backend.   Maybe
we need drastic rewrite to gtm-proxy at the merge.

Regards;
----------
Koichi Suzuki


2012/7/14 Andrei Martsinchyk <and...@gm...>:
> We have an idea to merge GTM Proxy into the XC core and make it an auxiliary
> process, like pooler, background writer, logger, etc.
> Like any other auxiliary process it would be started with the node, stopped
> with the node and serve sessions running under the same postmaster. The
> session would be always communicate to GTM via internal proxy. Configuration
> parameters specific to GTM proxy will be moved to the main config file, some
> of them like GTM host/port are already there, they would be used by the
> Proxy, session would be connected to the port where it is listening, it
> would be in the same config file.
> We see following benefits of doing this:
> - We force people to connect to GTM via proxy and achieve better
> performance.
> - Better maintainability: -1 configuration file, -1 log file, -1 entity to
> manage and monitor. The proxy would share main configuration log, main log
> file, and postmaster would monitor proxy and restart if it fails, the
> housekeeping code is already here.
> - Effectiveness: having proxy running under the same postmaster as its
> clients would allow to use faster communication channels, like unix sockets,
> pipes, shared memory.
> - Reliability: if main GTM server goes down GTM proxy able to reconnect to a
> promoted standby, but not session. If session would always connect to the
> proxy it always would be able to reconnect.
> The only drawback we see is that the multiple nodes would not be able to
> share the same proxy.
> So, any ideas? Is it worth doing? Any pros and cons we are missing?
>
> --
> Andrei Martsinchyk
>
> StormDB - http://www.stormdb.com
> The Database Cloud
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

+1 for Michael's idea.     Because tables are created by CREATE TABLE
and dropped by DROP TABLE, it is quite natural to change the
distribution with ALTER TABLE.

It is very important to maintain SQL interface.

Current Michael's implementation requires involved tables locked, it
means that applications are blocked.     As found in the feature
request, we need redistribution to be done in backend.    This was
discussed in the cluster summit in PGCon 2012.    This does not
require to block application while redistribution are being done and
will be nice for some cluster operation scene.

Operation with tables locked is simpler and faster so I think we have
use cases for both.    Because the feature is the same, it is natural
to provide these (foreground and background) redistribution in the
same manner.   It is also very very difficult to provide background
redistribution without the core extension.    So I think it is quite
reasonable decision to provide them as ALTER TABLE.

Background ALTER TABLE could be provided as "ALTER TABLE ....
CONCURRENTLY" as done in CREATE INDEX.

Regards;
----------
Koichi Suzuki


2012/7/14 Michael Paquier <mic...@gm...>:
>
>
> On Sat, Jul 14, 2012 at 1:01 AM, Nikhil Sontakke <ni...@st...>
> wrote:
>>
>> > But, one thing that is essential is catalog updates. Are you suggesting
>> > that
>> > the catalog updates too should be done using some SQL?
>>
>> Surely, we can do:
>>
>> BEGIN;
>>
>> CREATE NODE; /* Hmm, I think we should have a CREATE CLUSTER NODE
>> version*/
>>
>> ALL the redistribution SQL here;
>>
>> COMMIT;
>>
>> The new node info will be visible to the rest of the SQL commands that
>> follow this ways.
>>
>> Michael, I don't have a strong view against adding stuff in the core,
>> but since the first cut for redistribution seems to be a bunch of SQL
>> grouped together, I thought this might be worth investigating too.
>
> Honestly I thought about such solutions before beginning my stuff, but
> arrived at the conclusion that we need a native way to manage
> redistribution. In this case, you fall under the following limitations:
> - How to manage node-level granularity for redistribution operations? In XC,
> by design, a SQL is launched globally on the cluster. At the exception of
> EXECUTE DIRECT but it only allows SELECT commands.
> - When and how to manage the catalog update? Even if it is possible to
> update catalog with DMLs, we need native APIs to be able to modify catalog
> entries.
> - CREATE NODE is used for the addition and deletion of nodes. Data
> redistribution does not concern changing the configuration of the cluster.
> You got a certain number of Datanodes, Coordinators, and you want to change
> the nodes where data of a table is located inside this given cluster. Your
> approach makes redistribution dependent on cluster configuration and it is
> honestly not welcome to add such degrees of dependencies that may be a
> burden in the future if we change once again the way cluster is configured.
> - For certain redistribution operations, we do NOT always need a transaction
> block! Just take the example of a replicated table changed to a distributed
> table. You just need to send a DELETE query to remote nodes to remove only
> the tuples that do not satisfy a hash condition. This is one of those things
> I am working on now.
>
> To my mind, each argument here makes necessary this feature in core. All
> combined even strengthen my arguments.
>
>>
>> Regards,
>> Nikhils
>>
>> > Something I am afraid is not possible with an external utility is
>> > control of
>> > redistribution at node level. For example, an external contrib module or
>> > utility will launch SQL queries to xc that have to be treated as global.
>> > However, redistribution needs to take care of cases like for example the
>> > reduction of nodes for replicated tables. In this case you just need to
>> > delete the data from removed nodes. Another easy example is the case of
>> > an
>> > increase of nodes for replicated tables. You need to pick up data on
>> > coordinator and then send it only to the new nodes. Those simple
>> > examples
>> > need a core management to minimize the work of redistribution inside
>> > cluster.
>> >
>> > On 2012/07/13, at 15:09, Ashutosh Bapat
>> > <ash...@en...>
>> > wrote:
>> >
>> > Even, I am wondering if that would be better.
>> >
>> > But, one thing that is essential is catalog updates. Are you suggesting
>> > that
>> > the catalog updates too should be done using some SQL?
>> >
>> > Can you please expand more on your idea, may be providing some examples,
>> > pseudo-code etc.?
>> >
>> > On Fri, Jul 13, 2012 at 10:36 AM, Nikhil Sontakke <ni...@st...>
>> > wrote:
>> >>
>> >> Just a thought.
>> >>
>> >> If we have a utility which spews out all of these statements to
>> >> redistribute a table across node modifications, then we can just wrap
>> >> them inside a transaction block and just run that?
>> >>
>> >> Wont it save all of the core changes?
>> >>
>> >> Regards,
>> >> Nikhils
>> >>
>> >> On Fri, Jul 13, 2012 at 12:29 AM, Michael Paquier
>> >> <mic...@gm...> wrote:
>> >> > Hi all,
>> >> >
>> >> > Please find attached an updated patch adding redistribution
>> >> > optimizations
>> >> > for replicated tables.
>> >> > If the node subset of a replicated table is reduced, the necessary
>> >> > nodes
>> >> > are
>> >> > simply truncated.
>> >> > If it is increased, a COPY TO is done to fetch the data, and COPY
>> >> > FROM
>> >> > is
>> >> > done only on the necessary nodes.
>> >> > New regression tests have been added to test that.
>> >> >
>> >> > Regards,
>> >> >
>> >> >
>> >> > On Thu, Jul 12, 2012 at 5:30 PM, Michael Paquier
>> >> > <mic...@gm...>
>> >> > wrote:
>> >> >>
>> >> >> OK, here is the mammoth patch: 3000 lines including docs,
>> >> >> implementation
>> >> >> and  regressions.
>> >> >> The code has been realigned with current master.
>> >> >> This patch introduces the latest thing I am working on: the
>> >> >> redistribution
>> >> >> command tree planning and execution.
>> >> >>
>> >> >> As I explained before, a redistribution consists of a series of
>> >> >> commands
>> >> >> (TRUNCATE, REINDEX, DELETE, COPY FROM, COPY TO) that need to be
>> >> >> determined
>> >> >> depending on the new and old locator information of the relation.
>> >> >> Each
>> >> >> action can be done on a subset of nodes.
>> >> >> This patch introduces the basic infrastructure of the command tree
>> >> >> build
>> >> >> and execution.
>> >> >> For the time being, redistribution uses only what is called the
>> >> >> default
>> >> >> command tree consisting of:
>> >> >> 1) COPY TO
>> >> >> 2) TRUNCATE
>> >> >> 3) COPY FROM
>> >> >> 4) REINDEX
>> >> >> But this structure can be easily completed with more complicated
>> >> >> operations.
>> >> >> In this patch there is still a small thing missing which is the
>> >> >> possibility to launch a COPY FROM on a subset of nodes, particularly
>> >> >> useful
>> >> >> when redistribution consists of a replicated table whose set of
>> >> >> nodes
>> >> >> is
>> >> >> increased.
>> >> >> Compared to the last versions, the impact of redistribution in
>> >> >> tablecmds.c
>> >> >> is limited.
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> --
>> >> >> Michael Paquier
>> >> >> http://michael.otacoo.com
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Michael Paquier
>> >> > http://michael.otacoo.com
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Live Security Virtual Conference
>> >> > Exclusive live event will cover all the ways today's security and
>> >> > threat landscape has changed and how IT managers can respond.
>> >> > Discussions
>> >> > will include endpoint security, mobile security and the latest in
>> >> > malware
>> >> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> >> > _______________________________________________
>> >> > Postgres-xc-developers mailing list
>> >> > Pos...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> StormDB - http://www.stormdb.com
>> >> The Database Cloud
>> >
>> >
>> >
>> >
>> > --
>> > Best Wishes,
>> > Ashutosh Bapat
>> > EntepriseDB Corporation
>> > The Enterprise Postgres Company
>> >
>>
>>
>>
>> --
>> StormDB - http://www.stormdb.com
>> The Database Cloud
>
>
>
>
> --
> Michael Paquier
> http://michael.otacoo.com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>