postgres-xc-developers Mailing List for Postgres-XC

On Tue, Jul 17, 2012 at 5:35 PM, Ashutosh Bapat <
ash...@en...> wrote:

> Although it's a bug in 1.0, there will be very few (ideally 0) people
> doing updates to catalogs using SQL. So, this isn't a candidate for
> backpatching. If we hear about this bug from the field, we will add it.

Why not... A bug is a bug, but feel free to do as you wish.
-- 
Michael Paquier
http://michael.otacoo.com

Although it's a bug in 1.0, there will be very few (ideally 0) people doing
updates to catalogs using SQL. So, this isn't a candidate for backpatching.
If we hear about this bug from the field, we will add it.

On Tue, Jul 17, 2012 at 10:15 AM, Michael Paquier <mic...@gm...
> wrote:

> Hi,
>
> I haven't seen any problems with this patch.
> This should also be backpatched to 1.0 stable.
>
> Regards,
>
> On Mon, Jul 16, 2012 at 3:10 PM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>> Hi All,
>> Trying to update a catalog in XC, reports error "could not find relation
>> for oid = ...".
>>
>> PFA the fix for the same.
>>
>> --
>> 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
>>
>>
>
>
> --
> Michael Paquier
> http://michael.otacoo.com
>



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

I suppose global constraint requires similar additional feature as
separate coordinator/datanode.   There could be less overhead because
now datanode has direct access to some global things, not via
coordinator.

I agree we need careful research and design, and goal of the gain.

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


2012/7/17 Michael Paquier <mic...@gm...>:
>
>
> On Tue, Jul 17, 2012 at 1:23 PM, Ashutosh Bapat
> <ash...@en...> wrote:
>>
>>
>>
>> On Tue, Jul 17, 2012 at 8:10 AM, Andrei Martsinchyk
>> <and...@gm...> wrote:
>>>
>>> It is great that you are going to merge Coordinator and Datanode. Mason
>>> and I discussed this item but did not agreed upon, now I am getting
>>> majority. We would be interested in participating the discussion.
>>
>>
>> Before majority wins, I would give my vote against majority. ;)
>>
>> Please note that, I am not against doing coordinator and datanode merge,
>> but may be the time is not right. We have quite a few things on our plate
>> like constraints, HA inside XC, node addition/deletion, some SQL features.
>> We might want to focus on those to make XC a good product feature-wise and
>> stability-wise and then move on to the merge.
>>
>> I personally don't think coordinator and datanode merge is sure to give
>> performance advantage. So, we may spend time merging these two only to find
>> that it's not performing well, and thus backtrace wasting time.
>
> Just critically lowering inter-node data exchange and network load will
> allow a good performance gain for sure :)
> However I got the point about features we should do first like global
> constraints. And what if global constraints are easier to do after we did
> the merge? We don't know about that either. In this new architecture XC
> would deal not with 2 layers of nodes, but only 1.
> Globally it is worth to study the potential effort first.
> --
> Michael Paquier
> http://michael.otacoo.com

Yes.   We have lots of work issues toward 2.0 and unfortunately, I
would say coordinator/datanode merge may not begin until 2.0 is out.
 I'd appreciate if anybody does some preliminary work for this,
including a research of pros/cons of this approach, expected
performance gain, if any, etc.

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


2012/7/17 Ashutosh Bapat <ash...@en...>:
>
>
> On Tue, Jul 17, 2012 at 8:10 AM, Andrei Martsinchyk
> <and...@gm...> wrote:
>>
>> It is great that you are going to merge Coordinator and Datanode. Mason
>> and I discussed this item but did not agreed upon, now I am getting
>> majority. We would be interested in participating the discussion.
>
>
> Before majority wins, I would give my vote against majority. ;)
>
> Please note that, I am not against doing coordinator and datanode merge, but
> may be the time is not right. We have quite a few things on our plate like
> constraints, HA inside XC, node addition/deletion, some SQL features. We
> might want to focus on those to make XC a good product feature-wise and
> stability-wise and then move on to the merge.
>
> I personally don't think coordinator and datanode merge is sure to give
> performance advantage. So, we may spend time merging these two only to find
> that it's not performing well, and thus backtrace wasting time.
>
>>
>> Anyway, merging of Coordinator and Datanode and merging Proxy a differ in
>> term of code changes. First basically involves pooler, executor and planner
>> module changes, former needs a wrapper and integration into postmaster,
>> probably some refactoring in gtm and gtm proxy modules.
>> I think we can keep the proxy multithreaded, at least on the first
>> integration stage. The pooler already linked with the pthreads stuff, as it
>> is using libpq.
>> Indeed, I think we would keep the socket communication between backend and
>> pooler. I am not sure if Unix socket is any faster then TCP/IP socket, it
>> would be possible to use Unix sockets as well. Later on, we would be able to
>> use shared memory. If the proxy maintains a local copy of the GTM snapshot
>> in shared memory it will be better if process make their local copies from
>> that one, then send them around via sockets.
>>
>>
>> 2012/7/17 Koichi Suzuki <koi...@gm...>
>>>
>>> 2012/7/16 Michael Paquier <mic...@gm...>:
>>> > 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.
>>>
>>> Cascading GTM proxies is not supported yet and I'm not sure what gain
>>> we have with it.   I don't think it's reasonable to run
>>> coordinator/node instance for this purpose anyway.
>>>
>>> > 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.
>>>
>>> Okay.   Only one reason I expect for performance is we can save
>>> (local) socket communication between the backend and the proxy.
>>> However, if we make proxy a separate process, just sharing the binary,
>>> we could be suffered by another overhead (for example, pg_proc locks,
>>> etc).
>>>
>>> Because of the difference in the process mode, integrating proxy with
>>> coordinator/backend may need to rewrite the code.
>>>
>>> Regards;
>>> ---
>>> Koichi
>>>
>>> > --
>>> > Michael Paquier
>>> > http://michael.otacoo.com
>>
>>
>>
>>
>> --
>> Andrei Martsinchyk
>>
>> StormDB - http://www.stormdb.com
>> The Database Cloud
>>
>>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>

Hi,

I haven't seen any problems with this patch.
This should also be backpatched to 1.0 stable.

Regards,

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

> Hi All,
> Trying to update a catalog in XC, reports error "could not find relation
> for oid = ...".
>
> PFA the fix for the same.
>
> --
> 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
>
>


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

On Tue, Jul 17, 2012 at 1:23 PM, Ashutosh Bapat <
ash...@en...> wrote:

>
>
> On Tue, Jul 17, 2012 at 8:10 AM, Andrei Martsinchyk <
> and...@gm...> wrote:
>
>> It is great that you are going to merge Coordinator and Datanode. Mason
>> and I discussed this item but did not agreed upon, now I am getting
>> majority. We would be interested in participating the discussion.
>
>
> Before majority wins, I would give my vote against majority. ;)
>
> Please note that, I am not against doing coordinator and datanode merge,
> but may be the time is not right. We have quite a few things on our plate
> like constraints, HA inside XC, node addition/deletion, some SQL features.
> We might want to focus on those to make XC a good product feature-wise and
> stability-wise and then move on to the merge.
>
> I personally don't think coordinator and datanode merge is sure to give
> performance advantage. So, we may spend time merging these two only to find
> that it's not performing well, and thus backtrace wasting time.
>
Just critically lowering inter-node data exchange and network load will
allow a good performance gain for sure :)
However I got the point about features we should do first like global
constraints. And what if global constraints are easier to do after we did
the merge? We don't know about that either. In this new architecture XC
would deal not with 2 layers of nodes, but only 1.
Globally it is worth to study the potential effort first.
-- 
Michael Paquier
http://michael.otacoo.com

Oh, I worded it the wrong way. Sorry. Here is better wording.

Your mail said
----
In the last core
team meeting, we agreed not to include general ALTER TABLE feature in
CONCURRENT operation.
----

I didn't understand the purpose of word "CONCURRENT" in the current
context. The feature that Michael is working on is non-concurrent ALTER
TABLE (no other command can run with ALTER TABLE). I am not at all
suggesting that we change it. I am saying that our design should be such
that eventually we should be able to specify and execute ALTER TABLE
subcommands like add column/delete column (which change the row layout)
along-with redistribution commands. There is nothing going concurrent here.

Hope that clarifies.

On Tue, Jul 17, 2012 at 9:36 AM, Koichi Suzuki <koi...@gm...>wrote:

> People don't like to stop application operation.   It is very painful.
>   Current ALTER TABLE blocks application so we have to stop involved
> applications for a while.   CONCURRENT operation don't require this,
> although it may take longer.
>
> This is very important feature.
>
> Regards;
> ----------
> Koichi Suzuki
>
>
> 2012/7/17 Ashutosh Bapat <ash...@en...>:
> > Hi Suzuki-san,
> >
> > On Mon, Jul 16, 2012 at 8:09 PM, Koichi Suzuki <
> koi...@gm...>
> > wrote:
> >>
> >> 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.
> >>
> >
> > I don't understand the purpose behind concurrent operations? Do you mean
> > specifying multiple ALTER TABLE subcommands in the same ALTER TABLE
> command?
> > OR do you mean online redistribution. I am presuming you mean the first
> one.
> > But still need to confirm.
> >
> >>
> >> >
> >> > 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
> >> >
> >
> >
> >
> >
> > --
> > Best Wishes,
> > Ashutosh Bapat
> > EntepriseDB Corporation
> > The Enterprise Postgres Company
> >
>



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

On Tue, Jul 17, 2012 at 8:10 AM, Andrei Martsinchyk <
and...@gm...> wrote:

> It is great that you are going to merge Coordinator and Datanode. Mason
> and I discussed this item but did not agreed upon, now I am getting
> majority. We would be interested in participating the discussion.


Before majority wins, I would give my vote against majority. ;)

Please note that, I am not against doing coordinator and datanode merge,
but may be the time is not right. We have quite a few things on our plate
like constraints, HA inside XC, node addition/deletion, some SQL features.
We might want to focus on those to make XC a good product feature-wise and
stability-wise and then move on to the merge.

I personally don't think coordinator and datanode merge is sure to give
performance advantage. So, we may spend time merging these two only to find
that it's not performing well, and thus backtrace wasting time.


> Anyway, merging of Coordinator and Datanode and merging Proxy a differ in
> term of code changes. First basically involves pooler, executor and planner
> module changes, former needs a wrapper and integration into postmaster,
> probably some refactoring in gtm and gtm proxy modules.
> I think we can keep the proxy multithreaded, at least on the first
> integration stage. The pooler already linked with the pthreads stuff, as it
> is using libpq.
> Indeed, I think we would keep the socket communication between backend and
> pooler. I am not sure if Unix socket is any faster then TCP/IP socket, it
> would be possible to use Unix sockets as well. Later on, we would be able
> to use shared memory. If the proxy maintains a local copy of the GTM
> snapshot in shared memory it will be better if process make their local
> copies from that one, then send them around via sockets.
>
>
> 2012/7/17 Koichi Suzuki <koi...@gm...>
>
>> 2012/7/16 Michael Paquier <mic...@gm...>:
>> > 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.
>>
>> Cascading GTM proxies is not supported yet and I'm not sure what gain
>> we have with it.   I don't think it's reasonable to run
>> coordinator/node instance for this purpose anyway.
>>
>> > 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.
>>
>> Okay.   Only one reason I expect for performance is we can save
>> (local) socket communication between the backend and the proxy.
>> However, if we make proxy a separate process, just sharing the binary,
>> we could be suffered by another overhead (for example, pg_proc locks,
>> etc).
>>
>> Because of the difference in the process mode, integrating proxy with
>> coordinator/backend may need to rewrite the code.
>>
>> Regards;
>> ---
>> Koichi
>>
>> > --
>> > Michael Paquier
>> > http://michael.otacoo.com
>>
>
>
>
> --
> Andrei Martsinchyk
>
> StormDB - http://www.stormdb.com
> The Database Cloud
>
>
>


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

Because this is a bulk operation, applications may need full access to the table, I mean, read and write during the redistribution.    May be providec by lower level of locking.    People would like to see latest view of the table so running whole ALTER TABLE as a single transaction may not be satisfactory.

Regards;
---
Koichi Suzuki

On Tue, 17 Jul 2012 13:08:46 +0900
Michael Paquier <mic...@gm...> wrote:

> On Tue, Jul 17, 2012 at 1:06 PM, Koichi Suzuki <koi...@gm...>wrote:
> 
> > People don't like to stop application operation.   It is very painful.
> >   Current ALTER TABLE blocks application so we have to stop involved
> > applications for a while.   CONCURRENT operation don't require this,
> > although it may take longer.
> >
> By blocking application, I think it means that an exclusive lock is taken
> on the table being altered, so other sessions cannot access to it.
> In this case CONCURRENT means that we do an ALTER TABLE by taking a lower
> locking level and authorize other sessions to read and/or modify data
> altered.
> -- 
> Michael Paquier
> http://michael.otacoo.com

On Tue, Jul 17, 2012 at 1:06 PM, Koichi Suzuki <koi...@gm...>wrote:

> People don't like to stop application operation.   It is very painful.
>   Current ALTER TABLE blocks application so we have to stop involved
> applications for a while.   CONCURRENT operation don't require this,
> although it may take longer.
>
By blocking application, I think it means that an exclusive lock is taken
on the table being altered, so other sessions cannot access to it.
In this case CONCURRENT means that we do an ALTER TABLE by taking a lower
locking level and authorize other sessions to read and/or modify data
altered.
-- 
Michael Paquier
http://michael.otacoo.com

People don't like to stop application operation.   It is very painful.
  Current ALTER TABLE blocks application so we have to stop involved
applications for a while.   CONCURRENT operation don't require this,
although it may take longer.

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


2012/7/17 Ashutosh Bapat <ash...@en...>:
> Hi Suzuki-san,
>
> On Mon, Jul 16, 2012 at 8:09 PM, Koichi Suzuki <koi...@gm...>
> wrote:
>>
>> 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.
>>
>
> I don't understand the purpose behind concurrent operations? Do you mean
> specifying multiple ALTER TABLE subcommands in the same ALTER TABLE command?
> OR do you mean online redistribution. I am presuming you mean the first one.
> But still need to confirm.
>
>>
>> >
>> > 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
>> >
>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>

People don't like to stop application operation.   It is very painful.
  Current ALTER TABLE blocks application so we have to stop involved
applications for a while.   CONCURRENT operation don't require this,
although it may take longer.

This is very important feature.

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


2012/7/17 Ashutosh Bapat <ash...@en...>:
> Hi Suzuki-san,
>
> On Mon, Jul 16, 2012 at 8:09 PM, Koichi Suzuki <koi...@gm...>
> wrote:
>>
>> 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.
>>
>
> I don't understand the purpose behind concurrent operations? Do you mean
> specifying multiple ALTER TABLE subcommands in the same ALTER TABLE command?
> OR do you mean online redistribution. I am presuming you mean the first one.
> But still need to confirm.
>
>>
>> >
>> > 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
>> >
>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>

Hi Suzuki-san,

On Mon, Jul 16, 2012 at 8:09 PM, Koichi Suzuki <koi...@gm...>wrote:

> 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.
>
>
I don't understand the purpose behind concurrent operations? Do you mean
specifying multiple ALTER TABLE subcommands in the same ALTER TABLE
command? OR do you mean online redistribution. I am presuming you mean the
first one. But still need to confirm.


> >
> > 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
> >
>



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

It is great that you are going to merge Coordinator and Datanode. Mason and
I discussed this item but did not agreed upon, now I am getting majority.
We would be interested in participating the discussion.
Anyway, merging of Coordinator and Datanode and merging Proxy a differ in
term of code changes. First basically involves pooler, executor and planner
module changes, former needs a wrapper and integration into postmaster,
probably some refactoring in gtm and gtm proxy modules.
I think we can keep the proxy multithreaded, at least on the first
integration stage. The pooler already linked with the pthreads stuff, as it
is using libpq.
Indeed, I think we would keep the socket communication between backend and
pooler. I am not sure if Unix socket is any faster then TCP/IP socket, it
would be possible to use Unix sockets as well. Later on, we would be able
to use shared memory. If the proxy maintains a local copy of the GTM
snapshot in shared memory it will be better if process make their local
copies from that one, then send them around via sockets.


2012/7/17 Koichi Suzuki <koi...@gm...>

> 2012/7/16 Michael Paquier <mic...@gm...>:
> > 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.
>
> Cascading GTM proxies is not supported yet and I'm not sure what gain
> we have with it.   I don't think it's reasonable to run
> coordinator/node instance for this purpose anyway.
>
> > 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.
>
> Okay.   Only one reason I expect for performance is we can save
> (local) socket communication between the backend and the proxy.
> However, if we make proxy a separate process, just sharing the binary,
> we could be suffered by another overhead (for example, pg_proc locks,
> etc).
>
> Because of the difference in the process mode, integrating proxy with
> coordinator/backend may need to rewrite the code.
>
> Regards;
> ---
> Koichi
>
> > --
> > Michael Paquier
> > http://michael.otacoo.com
>



-- 
Andrei Martsinchyk

StormDB - http://www.stormdb.com
The Database Cloud

2012/7/16 Michael Paquier <mic...@gm...>:
> 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.

Cascading GTM proxies is not supported yet and I'm not sure what gain
we have with it.   I don't think it's reasonable to run
coordinator/node instance for this purpose anyway.

> 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.

Okay.   Only one reason I expect for performance is we can save
(local) socket communication between the backend and the proxy.
However, if we make proxy a separate process, just sharing the binary,
we could be suffered by another overhead (for example, pg_proc locks,
etc).

Because of the difference in the process mode, integrating proxy with
coordinator/backend may need to rewrite the code.

Regards;
---
Koichi

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

Just a notice here. It was not in the initial design to allow redistribution in parallel of other alter table operations.

On 2012/07/16, at 21:20, Ashutosh Bapat <ash...@en...> wrote:

> 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.
Does this mean to fetch rows one by one and then resend them back to dedicated nodes? Could you be a little bit more clear about the possible methods usable here. This remark makes sense but you should be more explicit about HOW to do.
1) For example do you mean using a select to fetch each row, then initialize a COPY TO at the beginning of rewrite, then run a for loop on the tuples obtained, materialize them, rewrite them and then send them back with the COPY TO row by row? In this case is it possible to fetch data on a connection and then send data on it at the same time. Is it even possible?
2) do you mean to use the tuplestore that contains all the data fetched and then initialize a COPY at rewrite, and once again do a for loop on the tuplestore tuples, rewrite them and send them.

Seriously ideas are good, but ways to solve what you say, or just precisions about possible techniques and not vague assumptions would be better to save precious time. Your suggestions may require to change all the remote execution part for redistribution. It also highly probably makes most of your comments below useless.

Thanks.

> 
> Anyway, I have following comment 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
>