Now gtm-reconnect works with pgxc_ctl c version.
Kochidbms
Mar 18, 2013
Work inprogress
Today, did the following:
- Resolution of 9.2.3 merge with XC master.
- Test and debug pgxc_ctl C-version. Now it can configure all the slaves. Failover test will be done next.
Aug 2, 2012
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?
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?
Mar 7, 2012
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.
Mar 2, 2012
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 ....
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 ....
Feb 28, 2012
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.
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.
Jan 31, 2012
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.
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.
So far, from the discussion among the core members, we agreed that the test should consider at least three points of view.
- 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.
- 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.
- 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.
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.
Subscribe to:
Posts (Atom)