postgres-xc-developers Mailing List for Postgres-XC

---------- Forwarded message ----------
From: Michael Paquier <mic...@us...>
Date: Thu, Feb 17, 2011 at 11:06 PM
Subject: [Postgres-xc-committers] Postgres-XC branch, ha_support,
updated. v0.9.3-55-gd73ae51
To: pos...@li...


Project "Postgres-XC".

The branch, ha_support has been updated
      via  d73ae5182149b08e0728edb96eee339e0c0498b7 (commit)
     from  f42b489b49f366c78d816708d47b380f9db640d9 (commit)


- Log -----------------------------------------------------------------
commit d73ae5182149b08e0728edb96eee339e0c0498b7
Author: Michael P <mic...@us...>
Date:   Fri Feb 18 15:49:39 2011 +0900

   Mirroring and XCM (XC Cluster Manager) implementation


Hi Michael,

I will try and take a closer look when I have time.

Just wondering, have you guys done any measurements to show the
performance impact on DBT-1?

Thanks,

Mason

I took a look at the patch.   Basic idea is to use "name" rather than "oid".

Mason, I'd like to have your idea.   Because "OID" appears in so many
places, I think we should review if using "name" works in many cases
in the catalog search, I mean, general statements.    We've not
discussed much on this, especially integration of coordinator and
datanode catalog.   They're a little different, for example,
definition of aggregates.   I think we should consider this as well.

Because Michael is restoring "EXECUTE DIRECT", for the time being, we
may thing to allow this to more general use.   So far, EXECUTE DIRECT
is intended to be used by dedicated housekeeping, such as recovering
outstanding 2PCs when a coordinator crashes.

Any opinion/idea/comment is welcome.

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



2011/2/18 rahua1 <ra...@16...>:
> hi, koichi & mason:
>
> In postgresql regression test, only this case fails due to OID.
>
> Suggestion, given by mason, that use name instead of OID sounds simple &
> doable to fix this bug. So I try to do follow this way.
>
> Attachment is the code patch, any reply will be great appreciated.
>
>
>
>
> Best Regards!
>
> leo messi
>
> 2011-02-18
> ________________________________
> rahua1
> ________________________________
> 发件人: Mason <ma...@us...>
> 发送时间: 2011-02-14 10:47
> 主 题: Re: [Postgres-xc-developers] any good ways to resolve different oid
> between coordinators and datanodes?
> 收件人: koi...@gm...
> 抄 送: rahua1 <ra...@16...>, "pos...@li..."
> <pos...@li...>
>
>
>
> On Sun, Feb 13, 2011 at 4:52 PM, Koichi Suzuki <koi...@gm...> wrote:
>> Good point.
>>
>> Current XC does not enforce consistent OID among catalogs in
>> coordinators/datanodes.
>>
>> We have several candidate to improve it.
>>
>> 1. To enforce consistent OIDs among all the local catalogs.   This
>> will require to have separate OID system from user tables to reduce
>> coordinator <--> GTM communication for CREATE ... statement.   When a
>> coordinator proxy DDL statement to other coordinators/datanodes,
>> CREATE statement should be associated with such OID.
>
> Something like CREATE TABLE tab1 OID 1001 (col1 OID 1002  int, col2
> OID 1003...)? Basically, make sure every single item that creates a
> new row somewhere in pg_catalog has an OID explicitly assigned to it.
>
>>
>> 2. To have dedicated housekeeping psql interface such as "EXECUTE
>> DIRECT" which targets to specific coordinator/datanode.
>
> We may have talked about this a long time ago. I think one idea
> (yours?) was to convert every DDL statement to pg_catalog DML and
> execute on the other nodes. Maybe there is a little more work that
> would have to be done to make sure certain caches are invalidated if
> going that route.
>
> Either of these sound doable, but just would take some time.
>
>>
>> 1. will need some amount of code work (need to modify
>> coordinator/datanode DDL handling).   I'd like to know how serious
>> this limitation would be.
>
> Yes, this is difficult. Are there any other cases from pg_regress (or
> other cases encountered) that can be traced to OID issues, to get a
> better idea of the size of the problem? If there are not that many,
> you could consider just handling the special cases, like change how it
> is cached and use the name instead of the OID.  OTOH, perhaps there
> are more cases that come up in the future where it is useful to have
> these consistent.
>
> Regards,
>
> Mason
>
>
>>
>> Regards;
>> ----------
>> Koichi Suzuki
>>
>>
>>
>> 2011/2/12 rahua1 <ra...@16...>:
>>> when fixing bug# 3143333,
>>> BUG DETIALS:
>>>
>>> step:
>>> 1.create table with oids:
>>> create table test (x int, y int)with oids;
>>> 2.insert data;
>>> insert into test values(1,2);
>>> 3.create type:
>>> create type int_type as(a int, b int );
>>> 4.create table:
>>> create table int_test(z int, g int_type);
>>> 5.insert data:
>>> insert into int_test values(3,(4,5));
>>> 6.select statement :
>>> select * from int_test;
>>> 7.executed results:
>>> ERROR:  cache lookup failed for type 16391
>>>
>>>
>>>
>>> when created one data type after inserted one record into table with oids,
>>> the oid of self-defined data type is different between coordinator and
>>> datanode. PG-XC uses data type oid received from datanode to do cache
>>> lookup, so
>>> result descripted as bug#3143333 comes up.
>>> Any good ways to fix this bug?
>>> 2011-02-11
>>> ________________________________
>>> rahua1
>>> ------------------------------------------------------------------------------
>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>>> Pinpoint memory and threading errors before they happen.
>>> Find and fix more than 250 security defects in the development cycle.
>>> Locate bottlenecks in serial and parallel code that limit performance.
>>> http://p.sf.net/sfu/intel-dev2devfeb
>>> _______________________________________________
>>> Postgres-xc-developers mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>