postgres-xc-developers Mailing List for Postgres-XC

Hi,

Here is the patch with rergessions corrected.
Regards,

On Mon, Feb 20, 2012 at 1:47 PM, Michael Paquier
<mic...@gm...>wrote:

>
>
>> deparse_query is being used at a number of places including CTAS (which
>> is not FQS), in fact CTAS uses it to deparse CreateStmt (a utility). The
>> reason we should use deparse_query->get_query_def() is to have all the
>> context building at one place. get_query_def builds the context for query
>> deparsing. In deparse_utility_query() this code is duplicated. If in future
>> we want to change the way we deparse logic for XC, it's good to have
>> everything using a single function.
>>
> My latest patch gave up this idea, it was far too complicated and needed
> an effort (especially create table deparsing) that I am not sure I would be
> able to make by 1.0.
>
>>
>> Since, you are working in area of ProcessUtility(), I suggested it would
>> be good to have refactoring done now. The code in ProcessUtility() is
>> getting complicated for remote utilities because of it's recursive nature.
>> If we can take remote handling out of the recursion, there will no chance
>> of firing a utility to remote node multiple times. It will also become
>> maintainable and we will be able to add more utility support in XC easily
>> in future. I know, it's not part of support for SERIAL, but.
>>
> For sure. It is not on the top-priority though, and support for SERIAL is.
> Regards,
>
> --
> Michael Paquier
> http://michael.otacoo.com
>



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

>
> deparse_query is being used at a number of places including CTAS (which is
> not FQS), in fact CTAS uses it to deparse CreateStmt (a utility). The
> reason we should use deparse_query->get_query_def() is to have all the
> context building at one place. get_query_def builds the context for query
> deparsing. In deparse_utility_query() this code is duplicated. If in future
> we want to change the way we deparse logic for XC, it's good to have
> everything using a single function.
>
My latest patch gave up this idea, it was far too complicated and needed an
effort (especially create table deparsing) that I am not sure I would be
able to make by 1.0.

>
> Since, you are working in area of ProcessUtility(), I suggested it would
> be good to have refactoring done now. The code in ProcessUtility() is
> getting complicated for remote utilities because of it's recursive nature.
> If we can take remote handling out of the recursion, there will no chance
> of firing a utility to remote node multiple times. It will also become
> maintainable and we will be able to add more utility support in XC easily
> in future. I know, it's not part of support for SERIAL, but.
>
For sure. It is not on the top-priority though, and support for SERIAL is.
Regards,
-- 
Michael Paquier
http://michael.otacoo.com

> On Fri, Feb 17, 2012 at 7:29 PM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>> Michael,
>> I have following comments
>> 1. Instead of calling get_utility_query_def() call deparse_query().
>> That's common entry point for any deparsing in XC.
>
> 2. Why do you need to handle one statement and multiple statement cases
>> separately. Both of these cases can be handled in the same way, whichever
>> you want. See my first point below.
>>
> deparse_query is the entry point for the fqs planner.
> It would be unwise to gpo through this one knowing that we already know
> the type of query we are deparsiong, here a utility.
>

deparse_query is being used at a number of places including CTAS (which is
not FQS), in fact CTAS uses it to deparse CreateStmt (a utility). The
reason we should use deparse_query->get_query_def() is to have all the
context building at one place. get_query_def builds the context for query
deparsing. In deparse_utility_query() this code is duplicated. If in future
we want to change the way we deparse logic for XC, it's good to have
everything using a single function.

BTW. my second point is still unanswered.

Since, you are working in area of ProcessUtility(), I suggested it would be
good to have refactoring done now. The code in ProcessUtility() is getting
complicated for remote utilities because of it's recursive nature. If we
can take remote handling out of the recursion, there will no chance of
firing a utility to remote node multiple times. It will also become
maintainable and we will be able to add more utility support in XC easily
in future. I know, it's not part of support for SERIAL, but.


>
>
>> Following two comments are for your patch but utility handling in
>> general. Since, you are changing some of the utility handling in XC, may be
>> you can work on following directions to make code easy to understand and
>> manage.
>>
> Please understand that this patch is dedicated to the support of serial,
> and does not target anything related to general utility process. If any
> modifications are necessary, this could be the target of another patch.
>
>
>> 1. We are using two different mechanisms for sending utility statements
>> to remote nodes - a. create RemoteQuery node 2. Call
>> ExecUtilityStmtOnNodes(). This is not from your patch, but something
>> already existing. Can you please check do we need these two separate ways
>> and if there is way to eliminate one of them.
>>
> ExecUtilityStmtOnNodes in utility process is necessary to create on remote
> nodes the objects at the same time as the local node.
> RemoteQuery is used in case several relation objects are created at the
> same time. The current way of doing is consistent in the fact that
> utilities are launched on all the nodes in the same process launch.
>
> 2. In XC, when a coordinator received a utility statement, is there a
>> possibility that only some statements arising from the utility statement
>> should be executed on other nodes and not all?
>>
> This does not happen, a utility is launched on all the nodes. There are
> some special cases like views though that are launched only on Coordinators.
>
>> As I understand it, either the whole or none of the utility is executed
>> on other nodes. So, we should be able to separate the remote execution from
>> local execution and execute them one after the other. The local execution
>> will involve spawning other utility statements etc. Remote execution will
>> only send the original query to the remote node. The local execution on the
>> remote node will involve spawning other utility statements etc. We may not
>> want to create T_RemoteQuery node in the utility statements list and handle
>> it outside standard_ProcessUtility. There is a way to add a utility
>> handling hook ProcessUtility_hook, where you may be able to add XC specific
>> hook to do this.
>>
> I am not sure this is the purpose of this patch. It is more related to
> general utility handling.
>
> Regards,
>
>
>> On Fri, Feb 17, 2012 at 2:22 PM, Michael Paquier <
>> mic...@gm...> wrote:
>>
>>> Hi all,
>>>
>>> Please find attached a patch for the support of SERIAL, not tested with
>>> regressions.
>>> It uses the utility deparser technique, but this deparser is still very
>>> basic and configured only for create table, create sequence and alter
>>> sequence.
>>> Would the Postgres community be interested in that??
>>>
>>> --
>>> Michael Paquier
>>> http://michael.otacoo.com
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Virtualization & Cloud Management Using Capacity Planning
>>> Cloud computing makes use of virtualization - but cloud computing
>>> also focuses on allowing computing to be delivered as a service.
>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Michael Paquier
> http://michael.otacoo.com
>



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

Hi all,

Please find a largely simplified version of the patch to support SERIAL.
This is simple, works and does not impact the code heavily. The idea of
deparser was cool but it becomes really complicated when it is necessary to
manage constraints and extensions of CREATE TABLE in ruleutils.c.
Regressions are on the way.
Regards,

On Mon, Feb 20, 2012 at 10:47 AM, Michael Paquier <mic...@gm...
> wrote:

>
>
> On Fri, Feb 17, 2012 at 7:29 PM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>> Michael,
>> I have following comments
>> 1. Instead of calling get_utility_query_def() call deparse_query().
>> That's common entry point for any deparsing in XC.
>
> 2. Why do you need to handle one statement and multiple statement cases
>> separately. Both of these cases can be handled in the same way, whichever
>> you want. See my first point below.
>>
> deparse_query is the entry point for the fqs planner.
> It would be unwise to gpo through this one knowing that we already know
> the type of query we are deparsiong, here a utility.
>
>
>> Following two comments are for your patch but utility handling in
>> general. Since, you are changing some of the utility handling in XC, may be
>> you can work on following directions to make code easy to understand and
>> manage.
>>
> Please understand that this patch is dedicated to the support of serial,
> and does not target anything related to general utility process. If any
> modifications are necessary, this could be the target of another patch.
>
>
>> 1. We are using two different mechanisms for sending utility statements
>> to remote nodes - a. create RemoteQuery node 2. Call
>> ExecUtilityStmtOnNodes(). This is not from your patch, but something
>> already existing. Can you please check do we need these two separate ways
>> and if there is way to eliminate one of them.
>>
> ExecUtilityStmtOnNodes in utility process is necessary to create on remote
> nodes the objects at the same time as the local node.
> RemoteQuery is used in case several relation objects are created at the
> same time. The current way of doing is consistent in the fact that
> utilities are launched on all the nodes in the same process launch.
>
> 2. In XC, when a coordinator received a utility statement, is there a
>> possibility that only some statements arising from the utility statement
>> should be executed on other nodes and not all?
>>
> This does not happen, a utility is launched on all the nodes. There are
> some special cases like views though that are launched only on Coordinators.
>
>> As I understand it, either the whole or none of the utility is executed
>> on other nodes. So, we should be able to separate the remote execution from
>> local execution and execute them one after the other. The local execution
>> will involve spawning other utility statements etc. Remote execution will
>> only send the original query to the remote node. The local execution on the
>> remote node will involve spawning other utility statements etc. We may not
>> want to create T_RemoteQuery node in the utility statements list and handle
>> it outside standard_ProcessUtility. There is a way to add a utility
>> handling hook ProcessUtility_hook, where you may be able to add XC specific
>> hook to do this.
>>
> I am not sure this is the purpose of this patch. It is more related to
> general utility handling.
>
> Regards,
>
>
>> On Fri, Feb 17, 2012 at 2:22 PM, Michael Paquier <
>> mic...@gm...> wrote:
>>
>>> Hi all,
>>>
>>> Please find attached a patch for the support of SERIAL, not tested with
>>> regressions.
>>> It uses the utility deparser technique, but this deparser is still very
>>> basic and configured only for create table, create sequence and alter
>>> sequence.
>>> Would the Postgres community be interested in that??
>>>
>>> --
>>> Michael Paquier
>>> http://michael.otacoo.com
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Virtualization & Cloud Management Using Capacity Planning
>>> Cloud computing makes use of virtualization - but cloud computing
>>> also focuses on allowing computing to be delivered as a service.
>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Michael Paquier
> http://michael.otacoo.com
>



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

On Fri, Feb 17, 2012 at 7:29 PM, Ashutosh Bapat <
ash...@en...> wrote:

> Michael,
> I have following comments
> 1. Instead of calling get_utility_query_def() call deparse_query(). That's
> common entry point for any deparsing in XC.

2. Why do you need to handle one statement and multiple statement cases
> separately. Both of these cases can be handled in the same way, whichever
> you want. See my first point below.
>
deparse_query is the entry point for the fqs planner.
It would be unwise to gpo through this one knowing that we already know the
type of query we are deparsiong, here a utility.


> Following two comments are for your patch but utility handling in general.
> Since, you are changing some of the utility handling in XC, may be you can
> work on following directions to make code easy to understand and manage.
>
Please understand that this patch is dedicated to the support of serial,
and does not target anything related to general utility process. If any
modifications are necessary, this could be the target of another patch.


> 1. We are using two different mechanisms for sending utility statements to
> remote nodes - a. create RemoteQuery node 2. Call ExecUtilityStmtOnNodes().
> This is not from your patch, but something already existing. Can you please
> check do we need these two separate ways and if there is way to eliminate
> one of them.
>
ExecUtilityStmtOnNodes in utility process is necessary to create on remote
nodes the objects at the same time as the local node.
RemoteQuery is used in case several relation objects are created at the
same time. The current way of doing is consistent in the fact that
utilities are launched on all the nodes in the same process launch.

2. In XC, when a coordinator received a utility statement, is there a
> possibility that only some statements arising from the utility statement
> should be executed on other nodes and not all?
>
This does not happen, a utility is launched on all the nodes. There are
some special cases like views though that are launched only on Coordinators.

> As I understand it, either the whole or none of the utility is executed on
> other nodes. So, we should be able to separate the remote execution from
> local execution and execute them one after the other. The local execution
> will involve spawning other utility statements etc. Remote execution will
> only send the original query to the remote node. The local execution on the
> remote node will involve spawning other utility statements etc. We may not
> want to create T_RemoteQuery node in the utility statements list and handle
> it outside standard_ProcessUtility. There is a way to add a utility
> handling hook ProcessUtility_hook, where you may be able to add XC specific
> hook to do this.
>
I am not sure this is the purpose of this patch. It is more related to
general utility handling.

Regards,


> On Fri, Feb 17, 2012 at 2:22 PM, Michael Paquier <
> mic...@gm...> wrote:
>
>> Hi all,
>>
>> Please find attached a patch for the support of SERIAL, not tested with
>> regressions.
>> It uses the utility deparser technique, but this deparser is still very
>> basic and configured only for create table, create sequence and alter
>> sequence.
>> Would the Postgres community be interested in that??
>>
>> --
>> Michael Paquier
>> http://michael.otacoo.com
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> 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
>
>


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

Thanks, I spotted the error in remote query query planning.
When building the insert query in create_remoteinsert_plan, we do not check
if the attributes have being dropped or not, causing the local node to
check for types of data that do not exist. We have also the same problem
for remoteupdate and remotedelete.
The solution would be to bypass the columns dropped when building the
query, and to change data sent to remote node to bypass in slot the columns
that have been dropped.
Ideas?

On Fri, Feb 17, 2012 at 11:38 PM, Krzysztof Nowicki <
krz...@gm...> wrote:

> I found what cause issue, the problem appears after drop column. Look
> at following example:
>
> charon=> CREATE SEQUENCE id_seq;
> CREATE SEQUENCE
> charon=> CREATE TABLE test ( id int8 not null default
> nextval('id_seq'), name varchar(80), code varchar(80) );
> CREATE TABLE
> charon=> insert into test(name) values('aaa');
> INSERT 0 1
> charon=> alter table test drop column code;
> ALTER TABLE
> charon=> insert into test(name) values('aaa');
> ERROR:  cache lookup failed for type 0
>
> Best Wishes!
>
> Kris Nowicki
>
>
> 2012/2/17 Michael Paquier <mic...@gm...>:
> > Hi,
> >
> > I began to have a look at your problem but I am not able to reproduce it
> for
> > the time being even with tables of the same structure as yours.
> > 1) test 1
> > create table aa (a1 int default nextval('toto'), a2 numeric (30,5), a3
> > varchar(255), a4 varchar(255), a5 varchar(255), a6 varchar(255));
> > postgres=# insert into aa (a4) values ('yoyo');
> > INSERT 0 1
> > postgres=# insert into aa (a6) values ('yoyo');
> > INSERT 0 1
> >
> > 2) test 2
> > create table atacc1 (a int4 not null, b int4, c int4 not null, d int4);
> > alter table atacc1 drop a;
> > insert into atacc1 values (10, 11, 12, 13);
> > insert into atacc1 values (default, 11, 12, 13);
> > insert into atacc1 values (11, 12, 13);
> >
> > Could you provide some SQLs to be able to reproduce the problem?
> > I tried several scenarios to reproduce your problem but couldn't. The
> cause
> > might be a problem with table type reference, or it might be caused by
> the
> > foreign keys you use on the table I am not sure. I may not be able to
> spot
> > the problem without additional information.
> > Regards,
> >
> > On Thu, Feb 16, 2012 at 8:55 PM, Krzysztof Nowicki
> > <krz...@gm...> wrote:
> >>
> >> Additional log:
> >>
> >> 2012-02-16 11:50:22.006
> >> UTC,"charon","charon",560,"[local]",4f3ced27.230,22,"idle",2012-02-16
> >> 11:48:55 UTC,5/0,0,DEBUG,00000,"StartTransactionCommand",,,,,,"insert
> into
> >> developerfacet(legalname) values ('yoyo');",,,"psql"
> >> 2012-02-16 11:50:22.006
> >> UTC,"charon","charon",560,"[local]",4f3ced27.230,23,"idle",2012-02-16
> >> 11:48:55 UTC,5/129,0,DEBUG,00000,"StartTransaction",,,,,,"insert into
> >> developerfacet(legalname) values ('yoyo');",,,"psql"
> >> 2012-02-16 11:50:22.006
> >> UTC,"charon","charon",560,"[local]",4f3ced27.230,24,"idle",2012-02-16
> >> 11:48:55 UTC,5/129,0,DEBUG,00000,"name: unnamed; blockState:
> DEFAULT;
> >> state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
> ",,,,,,"insert
> >> into developerfacet(legalname) values ('yoyo');",,,"psql"
> >> 2012-02-16 11:50:22.007
> >> UTC,"charon","charon",560,"[local]",4f3ced27.230,25,"INSERT",2012-02-16
> >> 11:48:55 UTC,5/129,0,DEBUG,00000,"from GTM: xmin = 62272, xmax = 62272,
> xcnt
> >> = 0, RecGlobXmin = 62272",,,,,,"insert into developerfacet(legalname)
> values
> >> ('yoyo');",,,"psql"
> >> 2012-02-16 11:50:22.007
> >> UTC,"charon","charon",560,"[local]",4f3ced27.230,26,"INSERT",2012-02-16
> >> 11:48:55 UTC,5/129,0,DEBUG,00000,"func nextval(1574) is not
> >> immutable",,,,,,"insert into developerfacet(legalname) values
> >> ('yoyo');",,,"psql"
> >> 2012-02-16 11:50:22.007
> >> UTC,"charon","charon",560,"[local]",4f3ced27.230,27,"INSERT",2012-02-16
> >> 11:48:55 UTC,5/129,0,DEBUG,00000,"from GTM: xmin = 62272, xmax = 62272,
> xcnt
> >> = 0, RecGlobXmin = 62272",,,,,,"insert into developerfacet(legalname)
> values
> >> ('yoyo');",,,"psql"
> >> 2012-02-16 11:50:22.007
> >> UTC,"charon","charon",560,"[local]",4f3ced27.230,28,"INSERT",2012-02-16
> >> 11:48:55 UTC,5/129,0,DEBUG,00000,"ProcessQuery",,,,,,"insert into
> >> developerfacet(legalname) values ('yoyo');",,,"psql"
> >> 2012-02-16 11:50:22.008 UTC,,,30563,,4f3ce492.7763,58,,2012-02-16
> 11:12:18
> >> UTC,1/0,0,WARNING,01000,"Unexpected data on connection,
> >> cleaning.",,,,,,,,,""
> >> 2012-02-16 11:50:22.015 UTC,,,30563,,4f3ce492.7763,59,,2012-02-16
> 11:12:18
> >> UTC,1/0,0,DEBUG,00000,"Pooler: increased pool size to 1 for pool
> >> host=localhost port=15451 dbname=charon user=charon
> application_name=pgxc
> >> options='-c remotetype=coordinator'",,,,,,,,,""
> >> 2012-02-16 11:50:22.015 UTC,,,30563,,4f3ce492.7763,60,,2012-02-16
> 11:12:18
> >> UTC,1/0,0,WARNING,01000,"Unexpected data on connection,
> >> cleaning.",,,,,,,,,""
> >> 2012-02-16 11:50:22.024 UTC,,,30563,,4f3ce492.7763,61,,2012-02-16
> 11:12:18
> >> UTC,1/0,0,DEBUG,00000,"Pooler: increased pool size to 1 for pool
> >> host=10.178.232.171 port=15451 dbname=charon user=charon
> >> application_name=pgxc options='-c remotetype=coordinator'",,,,,,,,,""
> >> 2012-02-16 11:50:22.024 UTC,,,30563,,4f3ce492.7763,62,,2012-02-16
> 11:12:18
> >> UTC,1/0,0,WARNING,01000,"Unexpected data on connection,
> >> cleaning.",,,,,,,,,""
> >> 2012-02-16 11:50:22.033 UTC,,,30563,,4f3ce492.7763,63,,2012-02-16
> 11:12:18
> >> UTC,1/0,0,DEBUG,00000,"Pooler: increased pool size to 1 for pool
> >> host=10.178.232.171 port=15451 dbname=charon user=charon
> >> application_name=pgxc options='-c remotetype=coordinator'",,,,,,,,,""
> >> 2012-02-16 11:50:22.033
> >> UTC,"charon","charon",560,"[local]",4f3ced27.230,29,"INSERT",2012-02-16
> >> 11:48:55 UTC,5/129,0,DEBUG,00000,"autocommit = true, has primary =
> false,
> >> regular_conn_count = 2, need_tran = true",,,,,,"insert into
> >> developerfacet(legalname) values ('yoyo');",,,"psql"
> >> 2012-02-16 11:50:22.035
> >> UTC,"charon","charon",560,"[local]",4f3ced27.230,30,"INSERT",2012-02-16
> >> 11:48:55 UTC,5/129,0,ERROR,XX000,"cache lookup failed for type
> >> 0",,,,,,"insert into developerfacet(legalname) values
> ('yoyo');",,,"psql"
> >>
> >> 2012/2/16 Krzysztof Nowicki <krz...@gm...>
> >>>
> >>> Hi all,
> >>>
> >>> Can someone advise me what might cause this issue or what should I do
> to
> >>> get more info ?
> >>>
> >>>
> >>> ---------- Forwarded message ----------
> >>> From: Krzysztof Nowicki <krz...@gm...>
> >>> Date: 2012/2/15
> >>> Subject: cache lookup failed for type 0
> >>> To: mic...@gm...
> >>>
> >>>
> >>> Hi,
> >>>
> >>> I'm testing new release of postgres-xc 0.9.7 and I was stuck with cache
> >>> problem:
> >>>
> >>> charon=> \d developerfacet;
> >>>                                             Table
> "public.developerfacet"
> >>>             Column             |          Type          |
> >>>          Modifiers
> >>>
> >>>
> -------------------------------+------------------------+-------------------------------------------------------------
> >>>  id                            | bigint                 | not null
> >>> default nextval('developerfacet_id_seq'::regclass)
> >>>  currencycode                  | character varying(255) |
> >>>  amountvalue                   | numeric(30,5)          |
> >>>  localcurrencycode             | character varying(255) |
> >>>  canseeinvisibleincomingmsisdn | boolean                |
> >>>  legalname                     | character varying(255) |
> >>>  address                       | character varying(255) |
> >>>  ispobox                       | boolean                |
> >>>  addresscity                   | character varying(255) |
> >>>  addresszip                    | character varying(255) |
> >>>  addressstate                  | character varying(255) |
> >>>  addresscountry                | character varying(255) |
> >>>  taxregistrationno             | character varying(255) |
> >>>  nameofcontactperson           | character varying(255) |
> >>>  email                         | character varying(255) |
> >>>  phoneno                       | character varying(255) |
> >>>  faxno                         | character varying(255) |
> >>>  bankname                      | character varying(255) |
> >>>  bankaddress                   | character varying(255) |
> >>>  bankcity                      | character varying(255) |
> >>>  bankcountry                   | character varying(255) |
> >>>  bankaccountno                 | character varying(255) |
> >>>  code                          | character varying(3)   |
> >>>  bankcode                      | character varying(255) |
> >>>  bankcountrycode               | character varying(3)   |
> >>>  addresscountrycode            | character varying(3)   |
> >>>  newvendor                     | boolean                |
> >>>  vendorid                      | character varying(255) |
> >>> Indexes:
> >>>     "developerfacet_pkey" PRIMARY KEY, btree (id)
> >>> Referenced by:
> >>>     TABLE "account" CONSTRAINT "fk_account_developerfacet_id" FOREIGN
> KEY
> >>> (developerfacet_id) REFERENCES developerfacet(id)
> >>>     TABLE "application" CONSTRAINT "fk_application_developer_id"
> FOREIGN
> >>> KEY (developer_id) REFERENCES developerfacet(id)
> >>>     TABLE "payment" CONSTRAINT "fk_developer_id" FOREIGN KEY
> >>> (developer_id) REFERENCES developerfacet(id)
> >>>     TABLE "developerinvitationcode" CONSTRAINT
> >>> "fk_developerinvitationcode_developer_id" FOREIGN KEY (developer_id)
> >>> REFERENCES developerfacet(id)
> >>>
> >>> charon=> insert into developerfacet(legalname) values ('yoyo');
> >>> ERROR:  cache lookup failed for type 0
> >>> charon=> insert into developerfacet(currencycode, amountvalue,
> >>> localcurrencycode, canseeinvisibleincomingmsisdn, legalname, address,
> >>> ispobox, addresscity, addresszip, addressstate, addresscountry,
> >>> taxregistrationno, nameofcontactperson, email, phoneno,  faxno,
> bankname,
> >>> bankaddress, bankcity, bankcountry, bankaccountno, code, bankcode,
> >>> bankcountrycode, addresscountrycode, newvendor, vendorid) values
> ('USD',
> >>> 10.99, 'USD', true, 'name', 'address', true,
> >>>
> 'a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','a',true,'vendorid');
> >>> ERROR:  cache lookup failed for type 0
> >>>
> >>>
> >>> More detail try:
> >>>
> >>> charon=> insert into developerfacet(legalname) values ('yoyo');
> >>> DEBUG:  StartTransactionCommand
> >>> DEBUG:  StartTransaction
> >>> DEBUG:  name: unnamed; blockState:       DEFAULT; state: INPROGR,
> >>> xid/subid/cid: 0/1/0, nestlvl: 1, children:
> >>> DEBUG:  Postmaster child: connection established to GTM with string
> >>> host=localhost port=6666 node_name=coord1
> >>> DEBUG:  from GTM: xmin = 48806, xmax = 48806, xcnt = 0, RecGlobXmin =
> >>> 48806
> >>> DEBUG:  func nextval(1574) is not immutable
> >>> DEBUG:  from GTM: xmin = 48806, xmax = 48806, xcnt = 0, RecGlobXmin =
> >>> 48806
> >>> DEBUG:  ProcessQuery
> >>> DEBUG:  CommitTransaction
> >>> DEBUG:  name: unnamed; blockState:       STARTED; state: INPROGR,
> >>> xid/subid/cid: 0/1/0, nestlvl: 1, children:
> >>> DEBUG:  [re]setting xid = 0, old_value = 0
> >>> DEBUG:  autocommit = true, has primary = false, regular_conn_count = 2,
> >>> need_tran = true
> >>> ERROR:  cache lookup failed for type 0
> >>>
> >>>
> >>> Maybe you could help me with this problem ?
> >>>
> >>> Br,
> >>>
> >>> Kris Nowicki
> >>>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Virtualization & Cloud Management Using Capacity Planning
> >> Cloud computing makes use of virtualization - but cloud computing
> >> also focuses on allowing computing to be delivered as a service.
> >> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> >> _______________________________________________
> >> Postgres-xc-developers mailing list
> >> Pos...@li...
> >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >>
> >
> >
> >
> > --
> > Michael Paquier
> > http://michael.otacoo.com
>



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