Tested gtm-reconnect

Now gtm-reconnect works with pgxc_ctl c version.

Work inprogress

Today, did the following:

1. Resolution of 9.2.3 merge with XC master.
2. Test and debug pgxc_ctl C-version.  Now it can configure all the slaves.  Failover test will be done next.

Need to write the book chap1.

WAL Filtering for table rebalancing

Now XC team finished table rebalancing feature by ALTER TABLE ... DISTRIBUTE BY ... statement.   This runs with all the rows of the table locked.    The next is to do this concurrently, not locking rows and run everything background.   Different from other ALTER TABLE operation, this doesn't affect the logical view of the table and is safe to run this concurrently, as in the case of CREATE INDEX CONCURRENTLY.

To implement this, I thought to use a kind of log shipping for specific table.   To choose WAL records for the target table and then send them to the handler.   This looks very simple but we should consider TOAST as well.    Some says that it's much simpler to implement this as a part of walsender.  Yes, this can be if we don't have to worry about full page writes.

Full page writes are not simple to deal with.   We have to extract logical operation from them.   We can avoid this difficulty if the WAL filter is a part of XLogInsert(), which runs as each backend process and we need to handle this as well.

Which will be better?

XC conversation

XC developers ML received a comment on table rebalancing from a new guy.   His comment shows that he is really using XC.   He is from Shanghai Linux User Group. Considering the number of XC downloads, many Chinese people must be using or testing XC.  Very interesting.

Hint clause in XC?

I came to this idea.   This could be a wicked idea though.   In the future, we will see many statement which we cannot generate the best plan.   So, to do this, we may need to accept a hint which distribution to rely on, as

SELECT * FROM A,B,C WHERE A.A=B.B and B.B=C.C A.A in (SELECT Z from X WHERE Y=100) /*+ USE_PUSHDOWN TO ALL */

Looks tempting ....

XC at PGCon2012

Now PGCon2012 schedule is out.   Postgres-XC will have tutorial for building, installing, configuring and running Postgres-XC database cluster.   This is both for users and developers.    Developers will learn XC's source code configuration and documentation internals, although the tutorial will be best-tuned for users.
Tutorial will include everything they should know to use XC, including node configuration and table design.
Scheduled on May 16th, Wed., 1:00PM to 4:00PM.

Testing XC toward 1.0

Now we're becoming the goal of this quarter's development.   Depending upon each mender's schedule, we will go into dedicated test for 1.0.
So far, from the discussion among the core members, we agreed that the test should consider at least three points of view.

1. How many bugs are hidden and how many bugs should be found.    Considering the written code is around 100,000 lines, I think we should find around 500 bugs.    I do hope the code is much better.   We need much more test cases to run.
2. SQL functionality check: what is supported and what is not.    I've been discussion this with the sponsor.   I don't know if the developer team should (and can) do this.    From my experience, it will take at least five to six man-month to write a doc of test case for this purpose.
3. Code test coverage.   There could be a handy tool to measure this.   Although test code test coverage doesn't tell about the condition for each piece of code, Pavan tells this will be good to check the coverage of error handling.   I agree on this.

I should write first draft of XC test schedule by the next Tuesday to discuss in core member's teleconference.

After consideration...
Maybe increase code coverage makes most sense from current development team.   Feature test and performance test are being done for each development project.