postgres-xc-developers Mailing List for Postgres-XC (Page 4)

I understand this.   In a middle run, as discussed, we can qualify
CTID with the node OID so that it is globally unique.    Node OID can
be different from coordinator to coordinator but it is used only by
originating coordinator and should be okay.

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



2012/2/22 Michael Paquier <mic...@gm...>:
>
>
> On Wed, Feb 22, 2012 at 1:31 PM, Pavan Deolasee
> <pav...@en...> wrote:
>>
>> On Tue, Feb 21, 2012 at 4:17 PM, Pavan Deolasee
>> <pav...@en...> wrote:
>>
>> > DEBUG:  parse <unnamed>: DELETE FROM public.a WHERE a = $1 AND a = $2
>> > AND ctid = $3 AND ctid1 = $4 AND ctid2 = $5
>> > ERROR:  column "ctid1" does not exist at character 64
>> > STATEMENT:  DELETE FROM public.a WHERE a = $1 AND a = $2 AND ctid = $3
>> > AND ctid1 = $4 AND ctid2 = $5
>>
>> FWIW the following code fragment in createplan.c is generating this query/
>>
>> foreacch(elt, parse->targetList)
>> {
>>        TargetEntry *tle = lfirst(elt);
>>
>>        /* Set the clause if necessary */
>>        if (!is_where_created)
>>        {
>>                is_where_created = true;
>>                appendStringInfoString(buf, "WHERE ");
>>        }
>>        else
>>                appendStringInfoString(buf, "AND ");
>>
>>        appendStringInfo(buf, "%s = $%d ",
>>                        quote_identifier(tle->resname),
>>                        count);
>>
>>        /* Associate type of parameter */
>>        param_types[count - 1] = exprType((Node *) tle->expr);
>>        count++;
>> }
>>
>> I don't understand why we add all the columns in the targetlist to the
>> WHERE clause. Isn't it enough to just add CTID to identify the target
>> tuple ?
>
> CTID is not unique between nodes for distribute tables.
> It is indeed enough for replicated tables, as they should have consistent
> CTIDs, but for HASH tables, and even more for round robin tables we cannot
> do that.
> For hash tables, it may be possible to determine which is the node to target
> depending on the conditions given by users, but it is not always the case.
> For round robin table, it is even worse as you need extra-column data to be
> sure to eliminate the correct tuple.
>
> So for the time being so extra column data is added when looking for the
> correct tuple to eliminate.
> This would not be necessary if ctid mechanism incorporates an extension to
> manage node name to be sure that the wanted tuple is from correct node.
> --
> 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
>

On Wed, Feb 22, 2012 at 1:31 PM, Pavan Deolasee <
pav...@en...> wrote:

> On Tue, Feb 21, 2012 at 4:17 PM, Pavan Deolasee
> <pav...@en...> wrote:
>
> > DEBUG:  parse <unnamed>: DELETE FROM public.a WHERE a = $1 AND a = $2
> > AND ctid = $3 AND ctid1 = $4 AND ctid2 = $5
> > ERROR:  column "ctid1" does not exist at character 64
> > STATEMENT:  DELETE FROM public.a WHERE a = $1 AND a = $2 AND ctid = $3
> > AND ctid1 = $4 AND ctid2 = $5
>
> FWIW the following code fragment in createplan.c is generating this query/
>
> foreacch(elt, parse->targetList)
> {
>        TargetEntry *tle = lfirst(elt);
>
>        /* Set the clause if necessary */
>        if (!is_where_created)
>        {
>                is_where_created = true;
>                appendStringInfoString(buf, "WHERE ");
>        }
>        else
>                appendStringInfoString(buf, "AND ");
>
>        appendStringInfo(buf, "%s = $%d ",
>                        quote_identifier(tle->resname),
>                        count);
>
>        /* Associate type of parameter */
>        param_types[count - 1] = exprType((Node *) tle->expr);
>        count++;
> }
>
> I don't understand why we add all the columns in the targetlist to the
> WHERE clause. Isn't it enough to just add CTID to identify the target
> tuple ?
>
CTID is not unique between nodes for distribute tables.
It is indeed enough for replicated tables, as they should have consistent
CTIDs, but for HASH tables, and even more for round robin tables we cannot
do that.
For hash tables, it may be possible to determine which is the node to
target depending on the conditions given by users, but it is not always the
case.
For round robin table, it is even worse as you need extra-column data to be
sure to eliminate the correct tuple.

So for the time being so extra column data is added when looking for the
correct tuple to eliminate.
This would not be necessary if ctid mechanism incorporates an extension to
manage node name to be sure that the wanted tuple is from correct node.
-- 
Michael Paquier
http://michael.otacoo.com

On Tue, Feb 21, 2012 at 4:17 PM, Pavan Deolasee
<pav...@en...> wrote:

> DEBUG:  parse <unnamed>: DELETE FROM public.a WHERE a = $1 AND a = $2
> AND ctid = $3 AND ctid1 = $4 AND ctid2 = $5
> ERROR:  column "ctid1" does not exist at character 64
> STATEMENT:  DELETE FROM public.a WHERE a = $1 AND a = $2 AND ctid = $3
> AND ctid1 = $4 AND ctid2 = $5

FWIW the following code fragment in createplan.c is generating this query/

foreacch(elt, parse->targetList)
{
	TargetEntry *tle = lfirst(elt);

	/* Set the clause if necessary */
	if (!is_where_created)
	{
		is_where_created = true;
		appendStringInfoString(buf, "WHERE ");
	}
	else
		appendStringInfoString(buf, "AND ");

	appendStringInfo(buf, "%s = $%d ",
			quote_identifier(tle->resname),
			count);

	/* Associate type of parameter */
	param_types[count - 1] = exprType((Node *) tle->expr);
	count++;
}

I don't understand why we add all the columns in the targetlist to the
WHERE clause. Isn't it enough to just add CTID to identify the target
tuple ?

Thanks,
Pavan

-- 
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

Here is a test case I tried on master and it fails.

CREATE TABLE A (a int, b int);
CREATE TABLE B (a int, b int);
CREATE VIEW V AS SELECT tab1.a, tab1.b FROM A tab1, B tab2 WHERE
tab1.a = tab2.a;
CREATE RULE v_rule AS ON DELETE TO V DO INSTEAD DELETE FROM A WHERE a = OLD.a;
INSERT INTO A VALUES (1, 2);
INSERT INTO B VALUES (1, 2);
DELETE FROM V WHERE EXISTS (SELECT * FROM A);
ERROR:  Could not commit prepared transaction implicitly

The data node log shows the following:

LOG:  statement: START TRANSACTION ISOLATION LEVEL read committed READ WRITE
DEBUG:  unset snapshot info
DEBUG:  global snapshot info: gxmin: 1529, gxmax: 1529, gxcnt: 0
DEBUG:  parse <unnamed>: DELETE FROM public.a WHERE a = $1 AND a = $2
AND ctid = $3 AND ctid1 = $4 AND ctid2 = $5
ERROR:  column "ctid1" does not exist at character 64
STATEMENT:  DELETE FROM public.a WHERE a = $1 AND a = $2 AND ctid = $3
AND ctid1 = $4 AND ctid2 = $5
DEBUG:  unset snapshot info
LOG:  statement: PREPARE TRANSACTION 'T1529'
DEBUG:  [re]setting xid = 0, old_value = 1529
DEBUG:  unset snapshot info
DEBUG:  Received new gxid 1530
DEBUG:  [re]setting xid = 1530, old_value = 0
LOG:  statement: COMMIT PREPARED 'T1529'
ERROR:  prepared transaction with identifier "T1529" does not exist
STATEMENT:  COMMIT PREPARED 'T1529'

As you can see, the DELETE query references columns such as
ctid1/ctid2 which are obviously missing and hence we get an error.
(There is a subsequent issue that we ignore the error and still try to
PREPARE and COMMIT the transaction, but a part of that would get fixed
by the transaction management refactoring). But I think we need to
look at the DELETE and UPDATE code paths and see what is required to
fix this.

Thanks,
Pavan

-- 
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

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

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

After last test I created another table with default nextval to the
same sequence and it works so I'm not sure maybe it's not a problem
with sequence:

charon=> CREATE TABLE test2 ( id int8 not null default
nextval('tariff_id_seq'), name varchar(80) );
CREATE TABLE
charon=> insert into test2(name) values('aaa');
INSERT 0 1
charon=> insert into tariff(id) values(nextval('tariff_id_seq'));
ERROR:  cache lookup failed for type 0
charon=>

2012/2/17 Krzysztof Nowicki <krz...@gm...>
>
> I made a test to check if cause might be with table type reference or foreign keys. I simplified table that it has only id with default nextval (earlier it had table type reference and foreign keys). After this problem still exists so it's probably something related to sequence.
>
>
> \d tariff
>                                    Table "public.tariff"
>    Column    |          Type          |                      Modifiers
> -------------+------------------------+-----------------------------------------------------
>  id          | bigint                 | not null default nextval('tariff_id_seq'::regclass)
>
> charon=> select currval('tariff_id_seq');
>  currval
> ---------
>       26
> (1 row)
>
> charon=> insert into tariff(id) values(nextval('tariff_id_seq'));
> ERROR:  cache lookup failed for type 0
> -------------------------------------------------------------
> 12-02-17 10:13:19.006 UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,113,"idle",2012-02-17 10:11:33 UTC,5/0,0,DEBUG,00000,"StartTransactionCommand",,,,,,"insert into tariff(id) values(nextval('tariff_id_seq'));",,,"psql"
> 2012-02-17 10:13:19.006 UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,114,"idle",2012-02-17 10:11:33 UTC,5/6414,0,DEBUG,00000,"StartTransaction",,,,,,"insert into tariff(id) values(nextval('tariff_id_seq'));",,,"psql"
> 2012-02-17 10:13:19.006 UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,115,"idle",2012-02-17 10:11:33 UTC,5/6414,0,DEBUG,00000,"name: unnamed; blockState:       DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: ",,,,,,"insert into tariff(id) values(nextval('tariff_id_seq'));",,,"psql"
> 2012-02-17 10:13:19.007 UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,116,"INSERT",2012-02-17 10:11:33 UTC,5/6414,0,DEBUG,00000,"from GTM: xmin = 78731, xmax = 78731, xcnt = 0, RecGlobXmin = 78731",,,,,,"insert into tariff(id) values(nextval('tariff_id_seq'));",,,"psql"
> 2012-02-17 10:13:19.007 UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,117,"INSERT",2012-02-17 10:11:33 UTC,5/6414,0,DEBUG,00000,"func nextval(1574) is not immutable",,,,,,"insert into tariff(id) values(nextval('tariff_id_seq'));",,,"psql"
> 2012-02-17 10:13:19.008 UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,118,"INSERT",2012-02-17 10:11:33 UTC,5/6414,0,DEBUG,00000,"from GTM: xmin = 78731, xmax = 78731, xcnt = 0, RecGlobXmin = 78731",,,,,,"insert into tariff(id) values(nextval('tariff_id_seq'));",,,"psql"
> 2012-02-17 10:13:19.008 UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,119,"INSERT",2012-02-17 10:11:33 UTC,5/6414,0,DEBUG,00000,"ProcessQuery",,,,,,"insert into tariff(id) values(nextval('tariff_id_seq'));",,,"psql"
> 2012-02-17 10:13:19.008 UTC,,,30563,,4f3ce492.7763,416,,2012-02-16 11:12:18 UTC,1/0,0,WARNING,01000,"Unexpected data on connection, cleaning.",,,,,,,,,""
> 2012-02-17 10:13:19.015 UTC,,,30563,,4f3ce492.7763,417,,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-17 10:13:19.015 UTC,,,30563,,4f3ce492.7763,418,,2012-02-16 11:12:18 UTC,1/0,0,WARNING,01000,"Unexpected data on connection, cleaning.",,,,,,,,,""
> 2012-02-17 10:13:19.025 UTC,,,30563,,4f3ce492.7763,419,,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-17 10:13:19.025 UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,120,"INSERT",2012-02-17 10:11:33 UTC,5/6414,0,DEBUG,00000,"autocommit = true, has primary = false, regular_conn_count = 2, need_tran = true",,,,,,"insert into tariff(id) values(nextval('tariff_id_seq'));",,,"psql"
> 2012-02-17 10:13:19.027 UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,121,"INSERT",2012-02-17 10:11:33 UTC,5/6414,0,ERROR,XX000,"cache lookup failed for type 0",,,,,,"insert into tariff(id) values(nextval('tariff_id_seq'));",,,"psql"
> -----------------------------------------------------------
>
>
> charon=> select currval('tariff_id_seq');
>  currval
> ---------
>       27
> (1 row)
>
> charon=> insert into tariff(id) values(901);
> DEBUG:  Record transaction commit 78757
> INSERT 0 1
>
>
> BR,
>
> 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,
>
>

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.

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.

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

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

I made a test to check if cause might be with table type reference
or foreign keys. I simplified table that it has only id with default
nextval (earlier it had table type reference and foreign keys). After this
problem still exists so it's probably something related to sequence.


\d tariff
                                   Table "public.tariff"
   Column    |          Type          |                      Modifiers

-------------+------------------------+-----------------------------------------------------
 id          | bigint                 | not null default
nextval('tariff_id_seq'::regclass)

charon=> select currval('tariff_id_seq');
 currval
---------
      26
(1 row)

charon=> insert into tariff(id) values(nextval('tariff_id_seq'));
ERROR:  cache lookup failed for type 0
-------------------------------------------------------------
12-02-17 10:13:19.006
UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,113,"idle",2012-02-17
10:11:33 UTC,5/0,0,DEBUG,00000,"StartTransactionCommand",,,,,,"insert into
tariff(id) values(nextval('tariff_id_seq'));",,,"psql"
2012-02-17 10:13:19.006
UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,114,"idle",2012-02-17
10:11:33 UTC,5/6414,0,DEBUG,00000,"StartTransaction",,,,,,"insert into
tariff(id) values(nextval('tariff_id_seq'));",,,"psql"
2012-02-17 10:13:19.006
UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,115,"idle",2012-02-17
10:11:33 UTC,5/6414,0,DEBUG,00000,"name: unnamed; blockState:
DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
",,,,,,"insert into tariff(id) values(nextval('tariff_id_seq'));",,,"psql"
2012-02-17 10:13:19.007
UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,116,"INSERT",2012-02-17
10:11:33 UTC,5/6414,0,DEBUG,00000,"from GTM: xmin = 78731, xmax = 78731,
xcnt = 0, RecGlobXmin = 78731",,,,,,"insert into tariff(id)
values(nextval('tariff_id_seq'));",,,"psql"
2012-02-17 10:13:19.007
UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,117,"INSERT",2012-02-17
10:11:33 UTC,5/6414,0,DEBUG,00000,"func nextval(1574) is not
immutable",,,,,,"insert into tariff(id)
values(nextval('tariff_id_seq'));",,,"psql"
2012-02-17 10:13:19.008
UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,118,"INSERT",2012-02-17
10:11:33 UTC,5/6414,0,DEBUG,00000,"from GTM: xmin = 78731, xmax = 78731,
xcnt = 0, RecGlobXmin = 78731",,,,,,"insert into tariff(id)
values(nextval('tariff_id_seq'));",,,"psql"
2012-02-17 10:13:19.008
UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,119,"INSERT",2012-02-17
10:11:33 UTC,5/6414,0,DEBUG,00000,"ProcessQuery",,,,,,"insert into
tariff(id) values(nextval('tariff_id_seq'));",,,"psql"
2012-02-17 10:13:19.008 UTC,,,30563,,4f3ce492.7763,416,,2012-02-16 11:12:18
UTC,1/0,0,WARNING,01000,"Unexpected data on connection,
cleaning.",,,,,,,,,""
2012-02-17 10:13:19.015 UTC,,,30563,,4f3ce492.7763,417,,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-17 10:13:19.015 UTC,,,30563,,4f3ce492.7763,418,,2012-02-16 11:12:18
UTC,1/0,0,WARNING,01000,"Unexpected data on connection,
cleaning.",,,,,,,,,""
2012-02-17 10:13:19.025 UTC,,,30563,,4f3ce492.7763,419,,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-17 10:13:19.025
UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,120,"INSERT",2012-02-17
10:11:33 UTC,5/6414,0,DEBUG,00000,"autocommit = true, has primary = false,
regular_conn_count = 2, need_tran = true",,,,,,"insert into tariff(id)
values(nextval('tariff_id_seq'));",,,"psql"
2012-02-17 10:13:19.027
UTC,"charon","charon",22870,"[local]",4f3e27d5.5956,121,"INSERT",2012-02-17
10:11:33 UTC,5/6414,0,ERROR,XX000,"cache lookup failed for type
0",,,,,,"insert into tariff(id) values(nextval('tariff_id_seq'));",,,"psql"
-----------------------------------------------------------


charon=> select currval('tariff_id_seq');
 currval
---------
      27
(1 row)

charon=> insert into tariff(id) values(901);
DEBUG:  Record transaction commit 78757
INSERT 0 1


BR,

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

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

> Ah, now that I re-read your steps above, I realized that you were
> suggesting the same in a more complex language :-)
>
Yeah, this is due to my French accent in English :) A lot of people falls
in the trap.


> Anyways, I think thats what we should do to support SERIAL right now.
>
I'll try to take a couple of hours to implement that. Checking regressions
might take more time though.
-- 
Michael Paquier
http://michael.otacoo.com

On Fri, Feb 17, 2012 at 10:11 AM, Michael Paquier
<mic...@gm...> wrote:
>
>
> On Fri, Feb 17, 2012 at 1:36 PM, Pavan Deolasee
> <pav...@en...> wrote:
>>
>> On Fri, Feb 17, 2012 at 7:20 AM, Michael Paquier
>> <mic...@gm...> wrote:
>> > Hi all,
>> >
>> > I have been having a look at the code regarding SERIAL, and tried to
>> > evaluate the amount of effort necessary to support it.
>> > In PostgreSQL code, SERIAL table creation is done in 3 steps with such
>> > queries:
>> > create table aa (a serial);
>> >
>> > 1) Creation of a sequence associated to column a by the creation of a
>> > node
>> > CreateSeqStmt.
>> > 2) modification of this sequence by the creation of a node AlterSeqStmt
>> > 3) Creation of the table by the creation of a node CreateStmt. The
>> > column
>> > indexed as SERIAL is replaced by an integer with a default value being
>> > the
>> > nextval of the sequence previously created.
>>
>> What if we transform the original "create table aa (a serial)" query to:
>>
>> create sequence _aa_a_seq;
>> create table aa (a int DEFAULT nextval('_aa_a_seq'))
>>
>> Thats what PG does internally. I quickly tested the above mechanism
>> and it works fine. Of course, we need to see if there are any corner
>> cases and how do we handle DROP TABLE etc. But this might be a good
>> work around for now.
>
> That's more or less my idea.

Ah, now that I re-read your steps above, I realized that you were
suggesting the same in a more complex language :-) Anyways, I think
thats what we should do to support SERIAL right now.

Thanks,
Pavan

-- 
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

On Fri, Feb 17, 2012 at 1:36 PM, Pavan Deolasee <
pav...@en...> wrote:

> On Fri, Feb 17, 2012 at 7:20 AM, Michael Paquier
> <mic...@gm...> wrote:
> > Hi all,
> >
> > I have been having a look at the code regarding SERIAL, and tried to
> > evaluate the amount of effort necessary to support it.
> > In PostgreSQL code, SERIAL table creation is done in 3 steps with such
> > queries:
> > create table aa (a serial);
> >
> > 1) Creation of a sequence associated to column a by the creation of a
> node
> > CreateSeqStmt.
> > 2) modification of this sequence by the creation of a node AlterSeqStmt
> > 3) Creation of the table by the creation of a node CreateStmt. The column
> > indexed as SERIAL is replaced by an integer with a default value being
> the
> > nextval of the sequence previously created.
>
> What if we transform the original "create table aa (a serial)" query to:
>
> create sequence _aa_a_seq;
> create table aa (a int DEFAULT nextval('_aa_a_seq'))
>
> Thats what PG does internally. I quickly tested the above mechanism
> and it works fine. Of course, we need to see if there are any corner
> cases and how do we handle DROP TABLE etc. But this might be a good
> work around for now.
>
That's more or less my idea.
We just need to launch the queries one by one based on the utility nodes
received by utility processor.
The only point is that the query strings would be generated based on their
parse tree in utility.c.

There are still some problems with sequence DDL that cannot be executed
inside a transaction block though...
But this has always been a problem. X(
-- 
Michael Paquier
http://michael.otacoo.com

On Fri, Feb 17, 2012 at 7:20 AM, Michael Paquier
<mic...@gm...> wrote:
> Hi all,
>
> I have been having a look at the code regarding SERIAL, and tried to
> evaluate the amount of effort necessary to support it.
> In PostgreSQL code, SERIAL table creation is done in 3 steps with such
> queries:
> create table aa (a serial);
>
> 1) Creation of a sequence associated to column a by the creation of a node
> CreateSeqStmt.
> 2) modification of this sequence by the creation of a node AlterSeqStmt
> 3) Creation of the table by the creation of a node CreateStmt. The column
> indexed as SERIAL is replaced by an integer with a default value being the
> nextval of the sequence previously created.

What if we transform the original "create table aa (a serial)" query to:

create sequence _aa_a_seq;
create table aa (a int DEFAULT nextval('_aa_a_seq'))

Thats what PG does internally. I quickly tested the above mechanism
and it works fine. Of course, we need to see if there are any corner
cases and how do we handle DROP TABLE etc. But this might be a good
work around for now.

Thanks,
Pavan

-- 
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

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

>
>
> On Fri, Feb 17, 2012 at 9:50 AM, Michael Paquier <
> mic...@gm...> wrote:
>
>>
>>
>> On Fri, Feb 17, 2012 at 1:18 PM, Ashutosh Bapat <
>> ash...@en...> wrote:
>>
>>> That should not be the case, since I have refactored the
>>> ProcessUtility() to launch the query only once on the remote node. May be
>>> you need to use sentToRemote variable appropriately.
>>>
>>>>
>>>>
>>>>> A simple solution to solve that is to use the utility node deparser of
>>>>> ruleutils.c to generate on-the-fly the query string used by RemoteQuery for
>>>>> utilities in utility execution.
>>>>>
>>>>
>>>> That's something desirable, but there is a hitch. A utility statement
>>>> can spawn other utility statements recursively. Either we should send only
>>>> the original utility statement or all the leaf utility statements. If we
>>>> send any intermediate statements, they might spawn other utility statements
>>>> thus causing conflicts. To me sending the original statement looks safer,
>>>> because there is no straight way to gather all the leaf level utility
>>>> statements and send those at once.
>>>>
>>>>
>>> Oh, btw, the query string passed to ProcessUtility() may not necessarily
>>> reflect the parse tree passed along-with, not even for the original utility
>>> statements. See  ConvertTriggerToFK(). So, we should always generate the
>>> utility statement to be sent to the remote node by deparsing the parse
>>> tree, whether we do it for original query or the spawned queries.
>>>
>> So this means using a deparser before launching the query though the
>> utility executor as I proposed?
>>
>
> I don't understand what do you mean by utility executor. But the deparsing
> should happen only on the original parse tree and not the spawned once.
>
I mean utility process in utility.c => standard_ProcessUtility.
In my idea, we should generate the remote query locally before launching
ExecUtilityStmtOnNodes based on the parsetree of given node.
-- 
Michael Paquier
http://michael.otacoo.com

On Fri, Feb 17, 2012 at 9:50 AM, Michael Paquier
<mic...@gm...>wrote:

>
>
> On Fri, Feb 17, 2012 at 1:18 PM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>> That should not be the case, since I have refactored the ProcessUtility()
>> to launch the query only once on the remote node. May be you need to use
>> sentToRemote variable appropriately.
>>
>>>
>>>
>>>> A simple solution to solve that is to use the utility node deparser of
>>>> ruleutils.c to generate on-the-fly the query string used by RemoteQuery for
>>>> utilities in utility execution.
>>>>
>>>
>>> That's something desirable, but there is a hitch. A utility statement
>>> can spawn other utility statements recursively. Either we should send only
>>> the original utility statement or all the leaf utility statements. If we
>>> send any intermediate statements, they might spawn other utility statements
>>> thus causing conflicts. To me sending the original statement looks safer,
>>> because there is no straight way to gather all the leaf level utility
>>> statements and send those at once.
>>>
>>>
>> Oh, btw, the query string passed to ProcessUtility() may not necessarily
>> reflect the parse tree passed along-with, not even for the original utility
>> statements. See  ConvertTriggerToFK(). So, we should always generate the
>> utility statement to be sent to the remote node by deparsing the parse
>> tree, whether we do it for original query or the spawned queries.
>>
> So this means using a deparser before launching the query though the
> utility executor as I proposed?
>

I don't understand what do you mean by utility executor. But the deparsing
should happen only on the original parse tree and not the spawned once.


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



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

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

> That should not be the case, since I have refactored the ProcessUtility()
> to launch the query only once on the remote node. May be you need to use
> sentToRemote variable appropriately.
>
>>
>>
>>> A simple solution to solve that is to use the utility node deparser of
>>> ruleutils.c to generate on-the-fly the query string used by RemoteQuery for
>>> utilities in utility execution.
>>>
>>
>> That's something desirable, but there is a hitch. A utility statement can
>> spawn other utility statements recursively. Either we should send only the
>> original utility statement or all the leaf utility statements. If we send
>> any intermediate statements, they might spawn other utility statements thus
>> causing conflicts. To me sending the original statement looks safer,
>> because there is no straight way to gather all the leaf level utility
>> statements and send those at once.
>>
>>
> Oh, btw, the query string passed to ProcessUtility() may not necessarily
> reflect the parse tree passed along-with, not even for the original utility
> statements. See  ConvertTriggerToFK(). So, we should always generate the
> utility statement to be sent to the remote node by deparsing the parse
> tree, whether we do it for original query or the spawned queries.
>
So this means using a deparser before launching the query though the
utility executor as I proposed?
-- 
Michael Paquier
http://michael.otacoo.com

That should not be the case, since I have refactored the ProcessUtility()
to launch the query only once on the remote node. May be you need to use
sentToRemote variable appropriately.

>
>
>> A simple solution to solve that is to use the utility node deparser of
>> ruleutils.c to generate on-the-fly the query string used by RemoteQuery for
>> utilities in utility execution.
>>
>
> That's something desirable, but there is a hitch. A utility statement can
> spawn other utility statements recursively. Either we should send only the
> original utility statement or all the leaf utility statements. If we send
> any intermediate statements, they might spawn other utility statements thus
> causing conflicts. To me sending the original statement looks safer,
> because there is no straight way to gather all the leaf level utility
> statements and send those at once.
>
>
Oh, btw, the query string passed to ProcessUtility() may not necessarily
reflect the parse tree passed along-with, not even for the original utility
statements. See  ConvertTriggerToFK(). So, we should always generate the
utility statement to be sent to the remote node by deparsing the parse
tree, whether we do it for original query or the spawned queries.

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


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

On Fri, Feb 17, 2012 at 7:20 AM, Michael Paquier
<mic...@gm...>wrote:

> Hi all,
>
> I have been having a look at the code regarding SERIAL, and tried to
> evaluate the amount of effort necessary to support it.
> In PostgreSQL code, SERIAL table creation is done in 3 steps with such
> queries:
> create table aa (a serial);
>
> 1) Creation of a sequence associated to column a by the creation of a node
> CreateSeqStmt.
> 2) modification of this sequence by the creation of a node AlterSeqStmt
> 3) Creation of the table by the creation of a node CreateStmt. The column
> indexed as SERIAL is replaced by an integer with a default value being the
> nextval of the sequence previously created.
>
> In XC, we have the following problem.
> The 3 nodes are correctly created on remote Coordinator. But each time we
> enter in the utility execution, the query string used for RemoteQuery is
> the one user has launched, in my case "create table aa (a serial);".
> What happens is that we launch 3 times the "create table" query to remote
> nodes, resulting in an error because this table has ever been created so
> the problem with XC is that the query launched to remote queries is not
> always consistent with what is launched with the utility nodes as we use
> only the query sent by application.
>

That should not be the case, since I have refactored the ProcessUtility()
to launch the query only once on the remote node. May be you need to use
sentToRemote variable appropriately.


> A simple solution to solve that is to use the utility node deparser of
> ruleutils.c to generate on-the-fly the query string used by RemoteQuery for
> utilities in utility execution.
>

That's something desirable, but there is a hitch. A utility statement can
spawn other utility statements recursively. Either we should send only the
original utility statement or all the leaf utility statements. If we send
any intermediate statements, they might spawn other utility statements thus
causing conflicts. To me sending the original statement looks safer,
because there is no straight way to gather all the leaf level utility
statements and send those at once.

Such a solution would be useful not only for SERIAL, but also for utility
> queries that generate subsequent nodes like inherited objects.
>
> Fortunately, the amount of effort is not that huge, there is already a
> structure in place in ruleutils.c (thanks Pavan) for CreateStmt, and this
> just needs to be extended for CreateSeqStmt and AlterSeqStmt.
> Any thoughts?
> --
> 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

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