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

If it is official, I believe Dan has posted it to Facebook but I've
not received it yet.   Maybe they need some more work.   Anyway, I
believe that they selected XC tutorial.

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



2012/2/25 Michael Paquier <mic...@gm...>:
> Hi all,
>
> This morning I found that the schedule for PGCon was loaded, and discovered
> that the tutorial of Postgres-XC has been accepted.
> Strangely, the schedule is not available anymore, so I wonder if what I saw
> was the final version.
> I could also see that no presentations have been accepted regarding XC. But
> once again it didn't look that schedule was finalized.
>
> Still, having a tutorial is great!
> Regards,
> --
> 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
>

Hi all,

This morning I found that the schedule for PGCon was loaded, and discovered
that the tutorial of Postgres-XC has been accepted.
Strangely, the schedule is not available anymore, so I wonder if what I saw
was the final version.
I could also see that no presentations have been accepted regarding XC. But
once again it didn't look that schedule was finalized.

Still, having a tutorial is great!
Regards,
-- 
Michael Paquier
http://michael.otacoo.com

Thanks Pavan.
I am unfortunately not available on Friday for the whole day, so will have
a look at that on Monday. I'll also run regressions at this moment.
Just from recalling of the first version of the patch, I am confident about
this version and its stability on the code.
Sudou-san may be able to test the patch in real load conditions tomorrow
though.

On Thu, Feb 23, 2012 at 8:52 PM, Pavan Deolasee <pav...@gm...>wrote:

> Hi All,
>
> Here is a final patch to implement the transaction handling. This now
> also support explicit 2PC. I have also reworked the auto-analyze proc
> handling. Instead of keeping a separate array, we just store the
> autovac procs at the start of the array and read XIDs from there to
> construct a local snapshot. This removes a lot of additional code from
> XC.
>
> The regression looks fine (around 40 failures). I am now going to
> spend some time on the error handling. But if we can run a quick DBT1
> test with this patch, that will give us a lot more confidence.
>
> Thanks,
> Pavan
>
> On Tue, Feb 14, 2012 at 3:45 PM, Michael Paquier
> <mic...@gm...> wrote:
> >>
> >> > 3) I found an assertion error at portal cleanup with your current
> patch
> >> > for
> >> > the test privileges.
> >> > (gdb) bt
> >> > #0  0x00007fad4fe85a75 in raise () from /lib/libc.so.6
> >> > #1  0x00007fad4fe895c0 in abort () from /lib/libc.so.6
> >> > #2  0x0000000000857b76 in ExceptionalCondition (conditionName=0xa44a90
> >> > "!(portal->cleanup == ((void *)0))",
> >> >     errorType=0xa4471c "FailedAssertion", fileName=0xa44710
> >> > "portalmem.c",
> >> > lineNumber=792) at assert.c:57
> >>
> >> I think I commented out this assertion as part of the second patch.
> >> May be you forgot to apply that.
> >
> > Yeah perhaps it was the same. Let's be care about that.
> >>
> >>
> >> > As you mentionned before, this may be a PostgreSQL bug.
> >> > 4) There are minor issues with tests guc, temp (functions using
> >> > temporary
> >> > objects in their expressions),
> >>
> >> Again, the is_temp flag is not set properly at few places and the
> >> second patch fixes that. I think there is still one extra failure
> >> regarding temp objects that I might have overlooked.
> >
> > Like other things, is_temp is related to the transaction, perhaps it may
> be
> > better to move it inside TransactionData?
> >
> >>
> >>
> >> > 5) Why not chaging the error message by an assert in
> >> > GenerateBeginCommand?
> >> > The sooner the better to detect bugs.
> >>
> >> Which error message you are referring to ? BTW, I renamed
> >> GenerateBeginCommand to generate_begin_command because its a static
> >> function (I know we are not very consistent), and I don't see any
> >> error message there.
> >
> > OK, I saw a comment in  GenerateBeginCommand about replacing the error
> > message in with an assert.
> > I just had a look at the path though in this area, and not at the file
> > changed, so I may have misunderstood smth.
> >>
> >>
> >> > 6) In AtEOXact_GlobalTxn, you can use something like
> >> > CommitPreparedTranGTM
> >> > in gtm.c to abort 2 transaction ids at the same time :)
> >>
> >> Yeah, may be :-) BTW, apart from combining the messages, does it serve
> >> any other purpose ? Do we need to send them at once for some
> >> correctness purpose ?
> >
> > CommitPreparedTranGTM is just here for performance purposes. It avoids
> to go
> > twice to GTM.
> >
> >>
> >>
> >> > 8) in pgxc_node_begin, we shouldn't really worry about non-shippable
> >> > expressions that may be sent down to datanodes. I think it is more the
> >> > planner responsability to evaluate that and not the remote node
> >> > executor.
> >> > The planner has already good evaluation APIs for that. It is then the
> >> > responsability of the dba to define customized expressions as pushable
> >> > even
> >> > if it should not.
> >>
> >> Do you mean the XXX comment I have written about the read-only vs
> >> read-write transaction ? Yeah, pgxc_node_begin() should just use
> >> whatever the caller has specified. I think the comment would be more
> >> appropriately placed in do_query() or any other such functions. I just
> >> wanted to add a caution about treating read-write statements as
> >> read-only, thus possibly compromising database state.
> >
> > OK, understood, it's also sufficient like this.
> >
> >>
> >>
> >> > 9) It is a design thought, but basically write and read connections
> are
> >> > part
> >> > of the current transaction, so why not putting them in TransactionData
> >> > instead of RemoteXactState in execRemote.c. Just wondering...
> >>
> >> I tried to put the remote transaction handling code in execRemote.c
> >> and the TransactionData structure is opaque to other modules. Also,
> >> the nodes are tracked in execRemote.c and also used in the same
> >> module. So it made sense to have them as static members in
> >> execRemote.c
> >
> > OK, it was just a thought. It makes sense also like this.
> >
> >>
> >>
> >> > It is pretty sad that the error messages are not correctly returned
> back
> >> > to
> >> > client even if transaction handling is cleaner and basics are in.
> >> > This is not an issue related to your patch though.
> >> >
> >>
> >> Yeah. Thats one thing I am wondering about too.  Especially, when
> >> different nodes report failures for different reasons at PREPARE or
> >> COMMIT time, which error should we report to the client ? This is not
> >> just an issue with transaction management, but where ever we have used
> >> combiner, I wonder how do we report multiple failures to the client ?
> >> Should we encapsulate that as some generic error message from the
> >> coordinator or should we report the first error or all errors from all
> >> the connections ? I think we need to take a call on this.
> >
> > There are a lot of ways to do about that. But if we think that XC should
> be
> > transparent to the application, we should return the first error
> message. We
> > could decide different strategies depending on the combiner type.
> > --
> > Michael Paquier
> > http://michael.otacoo.com
>
>
>
> --
> Pavan Deolasee
> EnterpriseDB     http://www.enterprisedb.com
>



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

On Thu, Feb 23, 2012 at 6:13 PM, Koichi Suzuki <koi...@gm...> wrote:

> Thank you Pavan;
>
> Ashutosh is now running DBT-1 and I hope you can share his experience.
>
>
I am not able to run it myself yet. Also, my DBT-1 is restricted to only my
laptop, which means all the coordinators, datanodes run on same machine
that too laptop. That's not real DBT-1 run.


> I will go back to pgxc_clean next week.
>
> Cheers;
> ----------
> Koichi Suzuki
>
>
>
> 2012/2/23 Pavan Deolasee <pav...@gm...>:
> > Hi All,
> >
> > Here is a final patch to implement the transaction handling. This now
> > also support explicit 2PC. I have also reworked the auto-analyze proc
> > handling. Instead of keeping a separate array, we just store the
> > autovac procs at the start of the array and read XIDs from there to
> > construct a local snapshot. This removes a lot of additional code from
> > XC.
> >
> > The regression looks fine (around 40 failures). I am now going to
> > spend some time on the error handling. But if we can run a quick DBT1
> > test with this patch, that will give us a lot more confidence.
> >
> > Thanks,
> > Pavan
> >
> > On Tue, Feb 14, 2012 at 3:45 PM, Michael Paquier
> > <mic...@gm...> wrote:
> >>>
> >>> > 3) I found an assertion error at portal cleanup with your current
> patch
> >>> > for
> >>> > the test privileges.
> >>> > (gdb) bt
> >>> > #0  0x00007fad4fe85a75 in raise () from /lib/libc.so.6
> >>> > #1  0x00007fad4fe895c0 in abort () from /lib/libc.so.6
> >>> > #2  0x0000000000857b76 in ExceptionalCondition
> (conditionName=0xa44a90
> >>> > "!(portal->cleanup == ((void *)0))",
> >>> >     errorType=0xa4471c "FailedAssertion", fileName=0xa44710
> >>> > "portalmem.c",
> >>> > lineNumber=792) at assert.c:57
> >>>
> >>> I think I commented out this assertion as part of the second patch.
> >>> May be you forgot to apply that.
> >>
> >> Yeah perhaps it was the same. Let's be care about that.
> >>>
> >>>
> >>> > As you mentionned before, this may be a PostgreSQL bug.
> >>> > 4) There are minor issues with tests guc, temp (functions using
> >>> > temporary
> >>> > objects in their expressions),
> >>>
> >>> Again, the is_temp flag is not set properly at few places and the
> >>> second patch fixes that. I think there is still one extra failure
> >>> regarding temp objects that I might have overlooked.
> >>
> >> Like other things, is_temp is related to the transaction, perhaps it
> may be
> >> better to move it inside TransactionData?
> >>
> >>>
> >>>
> >>> > 5) Why not chaging the error message by an assert in
> >>> > GenerateBeginCommand?
> >>> > The sooner the better to detect bugs.
> >>>
> >>> Which error message you are referring to ? BTW, I renamed
> >>> GenerateBeginCommand to generate_begin_command because its a static
> >>> function (I know we are not very consistent), and I don't see any
> >>> error message there.
> >>
> >> OK, I saw a comment in  GenerateBeginCommand about replacing the error
> >> message in with an assert.
> >> I just had a look at the path though in this area, and not at the file
> >> changed, so I may have misunderstood smth.
> >>>
> >>>
> >>> > 6) In AtEOXact_GlobalTxn, you can use something like
> >>> > CommitPreparedTranGTM
> >>> > in gtm.c to abort 2 transaction ids at the same time :)
> >>>
> >>> Yeah, may be :-) BTW, apart from combining the messages, does it serve
> >>> any other purpose ? Do we need to send them at once for some
> >>> correctness purpose ?
> >>
> >> CommitPreparedTranGTM is just here for performance purposes. It avoids
> to go
> >> twice to GTM.
> >>
> >>>
> >>>
> >>> > 8) in pgxc_node_begin, we shouldn't really worry about non-shippable
> >>> > expressions that may be sent down to datanodes. I think it is more
> the
> >>> > planner responsability to evaluate that and not the remote node
> >>> > executor.
> >>> > The planner has already good evaluation APIs for that. It is then the
> >>> > responsability of the dba to define customized expressions as
> pushable
> >>> > even
> >>> > if it should not.
> >>>
> >>> Do you mean the XXX comment I have written about the read-only vs
> >>> read-write transaction ? Yeah, pgxc_node_begin() should just use
> >>> whatever the caller has specified. I think the comment would be more
> >>> appropriately placed in do_query() or any other such functions. I just
> >>> wanted to add a caution about treating read-write statements as
> >>> read-only, thus possibly compromising database state.
> >>
> >> OK, understood, it's also sufficient like this.
> >>
> >>>
> >>>
> >>> > 9) It is a design thought, but basically write and read connections
> are
> >>> > part
> >>> > of the current transaction, so why not putting them in
> TransactionData
> >>> > instead of RemoteXactState in execRemote.c. Just wondering...
> >>>
> >>> I tried to put the remote transaction handling code in execRemote.c
> >>> and the TransactionData structure is opaque to other modules. Also,
> >>> the nodes are tracked in execRemote.c and also used in the same
> >>> module. So it made sense to have them as static members in
> >>> execRemote.c
> >>
> >> OK, it was just a thought. It makes sense also like this.
> >>
> >>>
> >>>
> >>> > It is pretty sad that the error messages are not correctly returned
> back
> >>> > to
> >>> > client even if transaction handling is cleaner and basics are in.
> >>> > This is not an issue related to your patch though.
> >>> >
> >>>
> >>> Yeah. Thats one thing I am wondering about too.  Especially, when
> >>> different nodes report failures for different reasons at PREPARE or
> >>> COMMIT time, which error should we report to the client ? This is not
> >>> just an issue with transaction management, but where ever we have used
> >>> combiner, I wonder how do we report multiple failures to the client ?
> >>> Should we encapsulate that as some generic error message from the
> >>> coordinator or should we report the first error or all errors from all
> >>> the connections ? I think we need to take a call on this.
> >>
> >> There are a lot of ways to do about that. But if we think that XC
> should be
> >> transparent to the application, we should return the first error
> message. We
> >> could decide different strategies depending on the combiner type.
> >> --
> >> Michael Paquier
> >> http://michael.otacoo.com
> >
> >
> >
> > --
> > Pavan Deolasee
> > EnterpriseDB     http://www.enterprisedb.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
> >
>
>
> ------------------------------------------------------------------------------
> 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

Thank you Pavan;

Ashutosh is now running DBT-1 and I hope you can share his experience.

I will go back to pgxc_clean next week.

Cheers;
----------
Koichi Suzuki



2012/2/23 Pavan Deolasee <pav...@gm...>:
> Hi All,
>
> Here is a final patch to implement the transaction handling. This now
> also support explicit 2PC. I have also reworked the auto-analyze proc
> handling. Instead of keeping a separate array, we just store the
> autovac procs at the start of the array and read XIDs from there to
> construct a local snapshot. This removes a lot of additional code from
> XC.
>
> The regression looks fine (around 40 failures). I am now going to
> spend some time on the error handling. But if we can run a quick DBT1
> test with this patch, that will give us a lot more confidence.
>
> Thanks,
> Pavan
>
> On Tue, Feb 14, 2012 at 3:45 PM, Michael Paquier
> <mic...@gm...> wrote:
>>>
>>> > 3) I found an assertion error at portal cleanup with your current patch
>>> > for
>>> > the test privileges.
>>> > (gdb) bt
>>> > #0  0x00007fad4fe85a75 in raise () from /lib/libc.so.6
>>> > #1  0x00007fad4fe895c0 in abort () from /lib/libc.so.6
>>> > #2  0x0000000000857b76 in ExceptionalCondition (conditionName=0xa44a90
>>> > "!(portal->cleanup == ((void *)0))",
>>> >     errorType=0xa4471c "FailedAssertion", fileName=0xa44710
>>> > "portalmem.c",
>>> > lineNumber=792) at assert.c:57
>>>
>>> I think I commented out this assertion as part of the second patch.
>>> May be you forgot to apply that.
>>
>> Yeah perhaps it was the same. Let's be care about that.
>>>
>>>
>>> > As you mentionned before, this may be a PostgreSQL bug.
>>> > 4) There are minor issues with tests guc, temp (functions using
>>> > temporary
>>> > objects in their expressions),
>>>
>>> Again, the is_temp flag is not set properly at few places and the
>>> second patch fixes that. I think there is still one extra failure
>>> regarding temp objects that I might have overlooked.
>>
>> Like other things, is_temp is related to the transaction, perhaps it may be
>> better to move it inside TransactionData?
>>
>>>
>>>
>>> > 5) Why not chaging the error message by an assert in
>>> > GenerateBeginCommand?
>>> > The sooner the better to detect bugs.
>>>
>>> Which error message you are referring to ? BTW, I renamed
>>> GenerateBeginCommand to generate_begin_command because its a static
>>> function (I know we are not very consistent), and I don't see any
>>> error message there.
>>
>> OK, I saw a comment in  GenerateBeginCommand about replacing the error
>> message in with an assert.
>> I just had a look at the path though in this area, and not at the file
>> changed, so I may have misunderstood smth.
>>>
>>>
>>> > 6) In AtEOXact_GlobalTxn, you can use something like
>>> > CommitPreparedTranGTM
>>> > in gtm.c to abort 2 transaction ids at the same time :)
>>>
>>> Yeah, may be :-) BTW, apart from combining the messages, does it serve
>>> any other purpose ? Do we need to send them at once for some
>>> correctness purpose ?
>>
>> CommitPreparedTranGTM is just here for performance purposes. It avoids to go
>> twice to GTM.
>>
>>>
>>>
>>> > 8) in pgxc_node_begin, we shouldn't really worry about non-shippable
>>> > expressions that may be sent down to datanodes. I think it is more the
>>> > planner responsability to evaluate that and not the remote node
>>> > executor.
>>> > The planner has already good evaluation APIs for that. It is then the
>>> > responsability of the dba to define customized expressions as pushable
>>> > even
>>> > if it should not.
>>>
>>> Do you mean the XXX comment I have written about the read-only vs
>>> read-write transaction ? Yeah, pgxc_node_begin() should just use
>>> whatever the caller has specified. I think the comment would be more
>>> appropriately placed in do_query() or any other such functions. I just
>>> wanted to add a caution about treating read-write statements as
>>> read-only, thus possibly compromising database state.
>>
>> OK, understood, it's also sufficient like this.
>>
>>>
>>>
>>> > 9) It is a design thought, but basically write and read connections are
>>> > part
>>> > of the current transaction, so why not putting them in TransactionData
>>> > instead of RemoteXactState in execRemote.c. Just wondering...
>>>
>>> I tried to put the remote transaction handling code in execRemote.c
>>> and the TransactionData structure is opaque to other modules. Also,
>>> the nodes are tracked in execRemote.c and also used in the same
>>> module. So it made sense to have them as static members in
>>> execRemote.c
>>
>> OK, it was just a thought. It makes sense also like this.
>>
>>>
>>>
>>> > It is pretty sad that the error messages are not correctly returned back
>>> > to
>>> > client even if transaction handling is cleaner and basics are in.
>>> > This is not an issue related to your patch though.
>>> >
>>>
>>> Yeah. Thats one thing I am wondering about too.  Especially, when
>>> different nodes report failures for different reasons at PREPARE or
>>> COMMIT time, which error should we report to the client ? This is not
>>> just an issue with transaction management, but where ever we have used
>>> combiner, I wonder how do we report multiple failures to the client ?
>>> Should we encapsulate that as some generic error message from the
>>> coordinator or should we report the first error or all errors from all
>>> the connections ? I think we need to take a call on this.
>>
>> There are a lot of ways to do about that. But if we think that XC should be
>> transparent to the application, we should return the first error message. We
>> could decide different strategies depending on the combiner type.
>> --
>> Michael Paquier
>> http://michael.otacoo.com
>
>
>
> --
> Pavan Deolasee
> EnterpriseDB     http://www.enterprisedb.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 Thu, Feb 23, 2012 at 4:52 PM, Pavan Deolasee
<pav...@gm...> wrote:
> Hi All,
>
> Here is a final patch to implement the transaction handling. This now
> also support explicit 2PC. I have also reworked the auto-analyze proc
> handling. Instead of keeping a separate array, we just store the
> autovac procs at the start of the array and read XIDs from there to
> construct a local snapshot. This removes a lot of additional code from
> XC.
>
> The regression looks fine (around 40 failures). I am now going to
> spend some time on the error handling. But if we can run a quick DBT1
> test with this patch, that will give us a lot more confidence.

Great...

Ref error handling, do we know what sort of issues we have around
error handling. Is that mostly a case of a transaction spanned over
multiple nodes and in-case of an error it is not properly rolled back
on all nodes?

>
> Thanks,
> Pavan
>
> On Tue, Feb 14, 2012 at 3:45 PM, Michael Paquier
> <mic...@gm...> wrote:
>>>
>>> > 3) I found an assertion error at portal cleanup with your current patch
>>> > for
>>> > the test privileges.
>>> > (gdb) bt
>>> > #0  0x00007fad4fe85a75 in raise () from /lib/libc.so.6
>>> > #1  0x00007fad4fe895c0 in abort () from /lib/libc.so.6
>>> > #2  0x0000000000857b76 in ExceptionalCondition (conditionName=0xa44a90
>>> > "!(portal->cleanup == ((void *)0))",
>>> >     errorType=0xa4471c "FailedAssertion", fileName=0xa44710
>>> > "portalmem.c",
>>> > lineNumber=792) at assert.c:57
>>>
>>> I think I commented out this assertion as part of the second patch.
>>> May be you forgot to apply that.
>>
>> Yeah perhaps it was the same. Let's be care about that.
>>>
>>>
>>> > As you mentionned before, this may be a PostgreSQL bug.
>>> > 4) There are minor issues with tests guc, temp (functions using
>>> > temporary
>>> > objects in their expressions),
>>>
>>> Again, the is_temp flag is not set properly at few places and the
>>> second patch fixes that. I think there is still one extra failure
>>> regarding temp objects that I might have overlooked.
>>
>> Like other things, is_temp is related to the transaction, perhaps it may be
>> better to move it inside TransactionData?
>>
>>>
>>>
>>> > 5) Why not chaging the error message by an assert in
>>> > GenerateBeginCommand?
>>> > The sooner the better to detect bugs.
>>>
>>> Which error message you are referring to ? BTW, I renamed
>>> GenerateBeginCommand to generate_begin_command because its a static
>>> function (I know we are not very consistent), and I don't see any
>>> error message there.
>>
>> OK, I saw a comment in  GenerateBeginCommand about replacing the error
>> message in with an assert.
>> I just had a look at the path though in this area, and not at the file
>> changed, so I may have misunderstood smth.
>>>
>>>
>>> > 6) In AtEOXact_GlobalTxn, you can use something like
>>> > CommitPreparedTranGTM
>>> > in gtm.c to abort 2 transaction ids at the same time :)
>>>
>>> Yeah, may be :-) BTW, apart from combining the messages, does it serve
>>> any other purpose ? Do we need to send them at once for some
>>> correctness purpose ?
>>
>> CommitPreparedTranGTM is just here for performance purposes. It avoids to go
>> twice to GTM.
>>
>>>
>>>
>>> > 8) in pgxc_node_begin, we shouldn't really worry about non-shippable
>>> > expressions that may be sent down to datanodes. I think it is more the
>>> > planner responsability to evaluate that and not the remote node
>>> > executor.
>>> > The planner has already good evaluation APIs for that. It is then the
>>> > responsability of the dba to define customized expressions as pushable
>>> > even
>>> > if it should not.
>>>
>>> Do you mean the XXX comment I have written about the read-only vs
>>> read-write transaction ? Yeah, pgxc_node_begin() should just use
>>> whatever the caller has specified. I think the comment would be more
>>> appropriately placed in do_query() or any other such functions. I just
>>> wanted to add a caution about treating read-write statements as
>>> read-only, thus possibly compromising database state.
>>
>> OK, understood, it's also sufficient like this.
>>
>>>
>>>
>>> > 9) It is a design thought, but basically write and read connections are
>>> > part
>>> > of the current transaction, so why not putting them in TransactionData
>>> > instead of RemoteXactState in execRemote.c. Just wondering...
>>>
>>> I tried to put the remote transaction handling code in execRemote.c
>>> and the TransactionData structure is opaque to other modules. Also,
>>> the nodes are tracked in execRemote.c and also used in the same
>>> module. So it made sense to have them as static members in
>>> execRemote.c
>>
>> OK, it was just a thought. It makes sense also like this.
>>
>>>
>>>
>>> > It is pretty sad that the error messages are not correctly returned back
>>> > to
>>> > client even if transaction handling is cleaner and basics are in.
>>> > This is not an issue related to your patch though.
>>> >
>>>
>>> Yeah. Thats one thing I am wondering about too.  Especially, when
>>> different nodes report failures for different reasons at PREPARE or
>>> COMMIT time, which error should we report to the client ? This is not
>>> just an issue with transaction management, but where ever we have used
>>> combiner, I wonder how do we report multiple failures to the client ?
>>> Should we encapsulate that as some generic error message from the
>>> coordinator or should we report the first error or all errors from all
>>> the connections ? I think we need to take a call on this.
>>
>> There are a lot of ways to do about that. But if we think that XC should be
>> transparent to the application, we should return the first error message. We
>> could decide different strategies depending on the combiner type.
>> --
>> Michael Paquier
>> http://michael.otacoo.com
>
>
>
> --
> Pavan Deolasee
> EnterpriseDB     http://www.enterprisedb.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
>



-- 
Ahsan Hadi
Snr Director Product Development
EnterpriseDB Corporation
The Enterprise Postgres Company

Phone: +92-51-8358874
Mobile: +92-333-5162114

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

Kris;

Thank you very much for the info.   I feel that we need some more test
for the combination of various predicates.   Your input is very
valuable.

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



2012/2/23 Krzysztof Nowicki <krz...@gm...>:
> Yes I confirm that bug exists on ver. 0.9.7 and on 1.0devel it's fixed.
>
> BR,
>
> Kris
>
> 2012/2/23 Koichi Suzuki <koi...@gm...>:
>> Okay.   We need the problem reproduction in 0.9.7 as well.   I have to
>> move to Shinagawa now so the test will be done afterwords.
>>
>> Regards;
>> ----------
>> Koichi Suzuki
>>
>>
>>
>> 2012/2/23 Pavan Deolasee <pav...@en...>:
>>> On Thu, Feb 23, 2012 at 10:10 AM, Koichi Suzuki <koi...@gm...> wrote:
>>>> Thanks.   So we determine the issue is fixed in the master.
>>>
>>> We can conclude so only if we are able to reproduce the issue on 0.9.7
>>> which is not very clear to me.
>>>
>>> Thanks,
>>> Pavan
>>
>> ------------------------------------------------------------------------------
>> 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

Hi All,

Here is a final patch to implement the transaction handling. This now
also support explicit 2PC. I have also reworked the auto-analyze proc
handling. Instead of keeping a separate array, we just store the
autovac procs at the start of the array and read XIDs from there to
construct a local snapshot. This removes a lot of additional code from
XC.

The regression looks fine (around 40 failures). I am now going to
spend some time on the error handling. But if we can run a quick DBT1
test with this patch, that will give us a lot more confidence.

Thanks,
Pavan

On Tue, Feb 14, 2012 at 3:45 PM, Michael Paquier
<mic...@gm...> wrote:
>>
>> > 3) I found an assertion error at portal cleanup with your current patch
>> > for
>> > the test privileges.
>> > (gdb) bt
>> > #0  0x00007fad4fe85a75 in raise () from /lib/libc.so.6
>> > #1  0x00007fad4fe895c0 in abort () from /lib/libc.so.6
>> > #2  0x0000000000857b76 in ExceptionalCondition (conditionName=0xa44a90
>> > "!(portal->cleanup == ((void *)0))",
>> >     errorType=0xa4471c "FailedAssertion", fileName=0xa44710
>> > "portalmem.c",
>> > lineNumber=792) at assert.c:57
>>
>> I think I commented out this assertion as part of the second patch.
>> May be you forgot to apply that.
>
> Yeah perhaps it was the same. Let's be care about that.
>>
>>
>> > As you mentionned before, this may be a PostgreSQL bug.
>> > 4) There are minor issues with tests guc, temp (functions using
>> > temporary
>> > objects in their expressions),
>>
>> Again, the is_temp flag is not set properly at few places and the
>> second patch fixes that. I think there is still one extra failure
>> regarding temp objects that I might have overlooked.
>
> Like other things, is_temp is related to the transaction, perhaps it may be
> better to move it inside TransactionData?
>
>>
>>
>> > 5) Why not chaging the error message by an assert in
>> > GenerateBeginCommand?
>> > The sooner the better to detect bugs.
>>
>> Which error message you are referring to ? BTW, I renamed
>> GenerateBeginCommand to generate_begin_command because its a static
>> function (I know we are not very consistent), and I don't see any
>> error message there.
>
> OK, I saw a comment in  GenerateBeginCommand about replacing the error
> message in with an assert.
> I just had a look at the path though in this area, and not at the file
> changed, so I may have misunderstood smth.
>>
>>
>> > 6) In AtEOXact_GlobalTxn, you can use something like
>> > CommitPreparedTranGTM
>> > in gtm.c to abort 2 transaction ids at the same time :)
>>
>> Yeah, may be :-) BTW, apart from combining the messages, does it serve
>> any other purpose ? Do we need to send them at once for some
>> correctness purpose ?
>
> CommitPreparedTranGTM is just here for performance purposes. It avoids to go
> twice to GTM.
>
>>
>>
>> > 8) in pgxc_node_begin, we shouldn't really worry about non-shippable
>> > expressions that may be sent down to datanodes. I think it is more the
>> > planner responsability to evaluate that and not the remote node
>> > executor.
>> > The planner has already good evaluation APIs for that. It is then the
>> > responsability of the dba to define customized expressions as pushable
>> > even
>> > if it should not.
>>
>> Do you mean the XXX comment I have written about the read-only vs
>> read-write transaction ? Yeah, pgxc_node_begin() should just use
>> whatever the caller has specified. I think the comment would be more
>> appropriately placed in do_query() or any other such functions. I just
>> wanted to add a caution about treating read-write statements as
>> read-only, thus possibly compromising database state.
>
> OK, understood, it's also sufficient like this.
>
>>
>>
>> > 9) It is a design thought, but basically write and read connections are
>> > part
>> > of the current transaction, so why not putting them in TransactionData
>> > instead of RemoteXactState in execRemote.c. Just wondering...
>>
>> I tried to put the remote transaction handling code in execRemote.c
>> and the TransactionData structure is opaque to other modules. Also,
>> the nodes are tracked in execRemote.c and also used in the same
>> module. So it made sense to have them as static members in
>> execRemote.c
>
> OK, it was just a thought. It makes sense also like this.
>
>>
>>
>> > It is pretty sad that the error messages are not correctly returned back
>> > to
>> > client even if transaction handling is cleaner and basics are in.
>> > This is not an issue related to your patch though.
>> >
>>
>> Yeah. Thats one thing I am wondering about too.  Especially, when
>> different nodes report failures for different reasons at PREPARE or
>> COMMIT time, which error should we report to the client ? This is not
>> just an issue with transaction management, but where ever we have used
>> combiner, I wonder how do we report multiple failures to the client ?
>> Should we encapsulate that as some generic error message from the
>> coordinator or should we report the first error or all errors from all
>> the connections ? I think we need to take a call on this.
>
> There are a lot of ways to do about that. But if we think that XC should be
> transparent to the application, we should return the first error message. We
> could decide different strategies depending on the combiner type.
> --
> Michael Paquier
> http://michael.otacoo.com



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

Yes I confirm that bug exists on ver. 0.9.7 and on 1.0devel it's fixed.

BR,

Kris

2012/2/23 Koichi Suzuki <koi...@gm...>:
> Okay.   We need the problem reproduction in 0.9.7 as well.   I have to
> move to Shinagawa now so the test will be done afterwords.
>
> Regards;
> ----------
> Koichi Suzuki
>
>
>
> 2012/2/23 Pavan Deolasee <pav...@en...>:
>> On Thu, Feb 23, 2012 at 10:10 AM, Koichi Suzuki <koi...@gm...> wrote:
>>> Thanks.   So we determine the issue is fixed in the master.
>>
>> We can conclude so only if we are able to reproduce the issue on 0.9.7
>> which is not very clear to me.
>>
>> Thanks,
>> Pavan
>
> ------------------------------------------------------------------------------
> 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

Okay.   We need the problem reproduction in 0.9.7 as well.   I have to
move to Shinagawa now so the test will be done afterwords.

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



2012/2/23 Pavan Deolasee <pav...@en...>:
> On Thu, Feb 23, 2012 at 10:10 AM, Koichi Suzuki <koi...@gm...> wrote:
>> Thanks.   So we determine the issue is fixed in the master.
>
> We can conclude so only if we are able to reproduce the issue on 0.9.7
> which is not very clear to me.
>
> Thanks,
> Pavan

On Thu, Feb 23, 2012 at 10:10 AM, Koichi Suzuki <koi...@gm...> wrote:
> Thanks.   So we determine the issue is fixed in the master.

We can conclude so only if we are able to reproduce the issue on 0.9.7
which is not very clear to me.

Thanks,
Pavan

Thanks.   So we determine the issue is fixed in the master.
----------
Koichi Suzuki



2012/2/23 Ashutosh Bapat <ash...@en...>:
> I tested the original query
>
> postgres=# CREATE TABLE t1 (id int8, name varchar(80));
> CREATE TABLE
> postgres=# CREATE TABLE t2 (id int8, name varchar(80));
> CREATE TABLE
> postgres=# CREATE TABLE t3 (id int8, name varchar(80));
> CREATE TABLE
> postgres=#
> postgres=#
> postgres=# select * from t1, t2, t3 where t1.id = t3.id AND t3.id is not
> null and
> postgres-# t1.name = 'test';
>
>  id | name | id | name | id | name
> ----+------+----+------+----+------
> (0 rows)
>
> postgres=# select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not
> null
> postgres(# and t1.name = 'test');
>
>  id | name | id | name | id | name
> ----+------+----+------+----+------
> (0 rows)
>
> postgres=# select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not
> null and t1.name = 'test');
>
>  id | name | id | name | id | name
> ----+------+----+------+----+------
> (0 rows)
>
> postgres=# explain verbose select * from t1, t2, t3 where t1.id = t3.id AND
> (t3.id is not null and t1.name = 'test');
>
> QUERY PLAN
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------------------------------------------------------------------------------
>  Nested Loop  (cost=0.00..3.05 rows=1 width=558)
>    Output: "__REMOTE_JOIN_QUERY__".id_1_1_1,
> "__REMOTE_JOIN_QUERY__".name_1_2_1, t2.id, t2.name,
> "__REMOTE_JOIN_QUERY__".id_3_1_1, "__REMOTE_JOIN_QUERY__".na
> me_3_2_1
>    ->  Materialize  (cost=0.00..0.00 rows=0 width=0)
>          Output: "__REMOTE_JOIN_QUERY__".id_1_1_1,
> "__REMOTE_JOIN_QUERY__".name_1_2_1, "__REMOTE_JOIN_QUERY__".id_3_1_1,
> "__REMOTE_JOIN_QUERY__".name_3_2_1
>          ->  Data Node Scan on "__REMOTE_JOIN_QUERY__"  (cost=0.00..1.01
> rows=1000 width=186)
>                Output: "__REMOTE_JOIN_QUERY__".id_1_1_1,
> "__REMOTE_JOIN_QUERY__".name_1_2_1, "__REMOTE_JOIN_QUERY__".id_3_1_1,
> "__REMOTE_JOIN_QUERY__".name_3
> _2_1
>                Node/s: datanode_1, datanode_2, datanode_3, datanode_4
>                Remote query: SELECT in_1.id AS id_1_1_1, in_1.name AS
> name_1_2_1, out_1.id AS id_3_1_1, out_1.name AS name_3_2_1 FROM  (SELECT id,
> name FROM
> ONLY t1 WHERE ((name)::text = 'test'::text)) in_1  ,  (SELECT id, name FROM
> ONLY t3 WHERE (id IS NOT NULL)) out_1  WHERE   (in_1.id = out_1.id)
>    ->  Data Node Scan on t2  (cost=0.00..1.01 rows=1000 width=186)
>          Output: t2.id, t2.name
>          Node/s: datanode_1, datanode_2, datanode_3, datanode_4
>          Remote query: SELECT id, name FROM ONLY t2 WHERE true
> (12 rows)
>
> postgres=# \q
>
>
>
> On Thu, Feb 23, 2012 at 10:05 AM, Koichi Suzuki <koi...@gm...>
> wrote:
>>
>> Thanks.   And you've tested the same query and tables as reported?  My
>> test is very simple and will not hit the bug.
>> ----------
>> Koichi Suzuki
>>
>>
>>
>> 2012/2/23 Ashutosh Bapat <ash...@en...>:
>> > OH, Sorry. By master, I mean the 1.0(devel) master.
>> >
>> >
>> > On Thu, Feb 23, 2012 at 9:54 AM, Koichi Suzuki <koi...@gm...>
>> > wrote:
>> >>
>> >> What version did you use?   I believe Kris used 0.9.7.   I also tested
>> >> with 0.9.7.
>> >>
>> >>
>> >> ----------
>> >> Koichi Suzuki
>> >>
>> >>
>> >>
>> >> 2012/2/23 Ashutosh Bapat <ash...@en...>:
>> >> > I ran it with the master, and couldn't reproduce the issue.
>> >> >
>> >> >
>> >> > On Thu, Feb 23, 2012 at 7:04 AM, Koichi Suzuki <koi...@gm...>
>> >> > wrote:
>> >> >>
>> >> >> Yeah, this may be the case.   We should run several test cases
>> >> >> (against 0.9.7 and master) to determine the cause.
>> >> >> ----------
>> >> >> Koichi Suzuki
>> >> >>
>> >> >>
>> >> >>
>> >> >> 2012/2/23 Michael Paquier <mic...@gm...>:
>> >> >> > In his case a 3rd table is used in the join but it doesn't use any
>> >> >> > join
>> >> >> > key
>> >> >> > in WHERE clause.
>> >> >> > It may be the cause of the bug.
>> >> >> >
>> >> >> >
>> >> >> > On Thu, Feb 23, 2012 at 9:58 AM, Koichi Suzuki
>> >> >> > <koi...@gm...>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> I tested more simplified case using 0.9.7 stable.
>> >> >> >>
>> >> >> >> koichi=# create table t (a int, b int);
>> >> >> >> CREATE TABLE
>> >> >> >> koichi=# koichi=# insert into t values (1,1);
>> >> >> >> INSERT 0 1
>> >> >> >> koichi=# insert into t (a) values (2);
>> >> >> >> INSERT 0 1
>> >> >> >> koichi=# select * from t;
>> >> >> >>  a | b
>> >> >> >> ---+---
>> >> >> >>  1 | 1
>> >> >> >>  2 |
>> >> >> >> (2 rows)
>> >> >> >>
>> >> >> >> koichi=# select * from t where b is not null;
>> >> >> >>  a | b
>> >> >> >> ---+---
>> >> >> >>  1 | 1
>> >> >> >> (1 row)
>> >> >> >>
>> >> >> >> koichi=# select * from t where b is null;
>> >> >> >>  a | b
>> >> >> >> ---+---
>> >> >> >>  2 |
>> >> >> >> (1 row)
>> >> >> >>
>> >> >> >> koichi=# create table t2 (c int, d int);
>> >> >> >> CREATE TABLE
>> >> >> >> koichi=# insert into t2 values (1,1), (2,2);
>> >> >> >> INSERT 0 2
>> >> >> >> koichi=# select * from t, t2 where a=c;
>> >> >> >>  a | b | c | d
>> >> >> >> ---+---+---+---
>> >> >> >>  1 | 1 | 1 | 1
>> >> >> >>  2 |   | 2 | 2
>> >> >> >> (2 rows)
>> >> >> >>
>> >> >> >> koichi=# select * from t, t2 where a=c and b is not null;
>> >> >> >>  a | b | c | d
>> >> >> >> ---+---+---+---
>> >> >> >>  1 | 1 | 1 | 1
>> >> >> >> (1 row)
>> >> >> >>
>> >> >> >> koichi=# select * from t, t2 where a=c and b is null;
>> >> >> >>  a | b | c | d
>> >> >> >> ---+---+---+---
>> >> >> >>  2 |   | 2 | 2
>> >> >> >> (1 row)
>> >> >> >>
>> >> >> >> koichi=# select * from t, t2 where a=c and b is not null and a =
>> >> >> >> 1;
>> >> >> >>  a | b | c | d
>> >> >> >> ---+---+---+---
>> >> >> >>  1 | 1 | 1 | 1
>> >> >> >> (1 row)
>> >> >> >>
>> >> >> >> koichi=# select * from t, t2 where a=c and (b is not null and a =
>> >> >> >> 1);
>> >> >> >>  a | b | c | d
>> >> >> >> ---+---+---+---
>> >> >> >>  1 | 1 | 1 | 1
>> >> >> >> (1 row)
>> >> >> >>
>> >> >> >> koichi=#
>> >> >> >>
>> >> >> >> The above looks "IS NULL" and "IS NOT NULL" is scanned correctly
>> >> >> >> in
>> >> >> >> some case.   Kris, could you let me know insert statement of your
>> >> >> >> case
>> >> >> >> to reproduce the problem?
>> >> >> >>
>> >> >> >> Regards;
>> >> >> >> ----------
>> >> >> >> Koichi Suzuki
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> 2012/2/23 Michael Paquier <mic...@gm...>:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Thu, Feb 23, 2012 at 1:09 AM, Krzysztof Nowicki
>> >> >> >> > <krz...@gm...> wrote:
>> >> >> >> >>
>> >> >> >> >> Hi all,
>> >> >> >> >>
>> >> >> >> >> I found another problem during testing ver. 0.9.7. Below steps
>> >> >> >> >> to
>> >> >> >> >> reproduce:
>> >> >> >> >>
>> >> >> >> >> CREATE TABLE t1 (id int8, name varchar(80));
>> >> >> >> >> CREATE TABLE t2 (id int8, name varchar(80));
>> >> >> >> >> CREATE TABLE t3 (id int8, name varchar(80));
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> select * from t1, t2, t3 where t1.id = t3.id AND t3.id is not
>> >> >> >> >> null
>> >> >> >> >> and
>> >> >> >> >> t1.name = 'test';
>> >> >> >> >>  id | name | id | name | id | name
>> >> >> >> >> ----+------+----+------+----+------
>> >> >> >> >> (0 rows)
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not
>> >> >> >> >> null
>> >> >> >> >> and t1.name = 'test');
>> >> >> >> >> ERROR:  could not open relation with OID 0
>> >> >> >> >
>> >> >> >> > The XC planner looks to be going crazy for such special case.
>> >> >> >> > At first sight, I would imagine that the "is not null" type is
>> >> >> >> > not
>> >> >> >> > scanned
>> >> >> >> > correctly.
>> >> >> >> > --
>> >> >> >> > 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
>> >> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > 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
>> >> >
>> >
>> >
>> >
>> >
>> > --
>> > Best Wishes,
>> > Ashutosh Bapat
>> > EntepriseDB Corporation
>> > The Enterprise Postgres Company
>> >
>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>

I tested the original query

postgres=# CREATE TABLE t1 (id int8, name varchar(80));
CREATE TABLE
postgres=# CREATE TABLE t2 (id int8, name varchar(80));
CREATE TABLE
postgres=# CREATE TABLE t3 (id int8, name varchar(80));
CREATE TABLE
postgres=#
postgres=#
postgres=# select * from t1, t2, t3 where t1.id = t3.id AND t3.id is not
null and
postgres-# t1.name = 'test';
 id | name | id | name | id | name
----+------+----+------+----+------
(0 rows)

postgres=# select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not
null
postgres(# and t1.name = 'test');
 id | name | id | name | id | name
----+------+----+------+----+------
(0 rows)

postgres=# select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not
null and t1.name = 'test');
 id | name | id | name | id | name
----+------+----+------+----+------
(0 rows)

postgres=# explain verbose select * from t1, t2, t3 where t1.id = t3.id AND
(t3.id is not null and t1.name = 'test');

QUERY PLAN


-------------------------------------------------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=0.00..3.05 rows=1 width=558)
   Output: "__REMOTE_JOIN_QUERY__".id_1_1_1,
"__REMOTE_JOIN_QUERY__".name_1_2_1, t2.id, t2.name,
"__REMOTE_JOIN_QUERY__".id_3_1_1, "__REMOTE_JOIN_QUERY__".na
me_3_2_1
   ->  Materialize  (cost=0.00..0.00 rows=0 width=0)
         Output: "__REMOTE_JOIN_QUERY__".id_1_1_1,
"__REMOTE_JOIN_QUERY__".name_1_2_1, "__REMOTE_JOIN_QUERY__".id_3_1_1,
"__REMOTE_JOIN_QUERY__".name_3_2_1
         ->  Data Node Scan on "__REMOTE_JOIN_QUERY__"  (cost=0.00..1.01
rows=1000 width=186)
               Output: "__REMOTE_JOIN_QUERY__".id_1_1_1,
"__REMOTE_JOIN_QUERY__".name_1_2_1, "__REMOTE_JOIN_QUERY__".id_3_1_1,
"__REMOTE_JOIN_QUERY__".name_3
_2_1
               Node/s: datanode_1, datanode_2, datanode_3, datanode_4
               Remote query: SELECT in_1.id AS id_1_1_1, in_1.name AS
name_1_2_1, out_1.id AS id_3_1_1, out_1.name AS name_3_2_1 FROM  (SELECT
id, name FROM
ONLY t1 WHERE ((name)::text = 'test'::text)) in_1  ,  (SELECT id, name FROM
ONLY t3 WHERE (id IS NOT NULL)) out_1  WHERE   (in_1.id = out_1.id)
   ->  Data Node Scan on t2  (cost=0.00..1.01 rows=1000 width=186)
         Output: t2.id, t2.name
         Node/s: datanode_1, datanode_2, datanode_3, datanode_4
         Remote query: SELECT id, name FROM ONLY t2 WHERE true
(12 rows)

postgres=# \q


On Thu, Feb 23, 2012 at 10:05 AM, Koichi Suzuki <koi...@gm...>wrote:

> Thanks.   And you've tested the same query and tables as reported?  My
> test is very simple and will not hit the bug.
> ----------
> Koichi Suzuki
>
>
>
> 2012/2/23 Ashutosh Bapat <ash...@en...>:
> > OH, Sorry. By master, I mean the 1.0(devel) master.
> >
> >
> > On Thu, Feb 23, 2012 at 9:54 AM, Koichi Suzuki <koi...@gm...>
> wrote:
> >>
> >> What version did you use?   I believe Kris used 0.9.7.   I also tested
> >> with 0.9.7.
> >>
> >>
> >> ----------
> >> Koichi Suzuki
> >>
> >>
> >>
> >> 2012/2/23 Ashutosh Bapat <ash...@en...>:
> >> > I ran it with the master, and couldn't reproduce the issue.
> >> >
> >> >
> >> > On Thu, Feb 23, 2012 at 7:04 AM, Koichi Suzuki <koi...@gm...>
> >> > wrote:
> >> >>
> >> >> Yeah, this may be the case.   We should run several test cases
> >> >> (against 0.9.7 and master) to determine the cause.
> >> >> ----------
> >> >> Koichi Suzuki
> >> >>
> >> >>
> >> >>
> >> >> 2012/2/23 Michael Paquier <mic...@gm...>:
> >> >> > In his case a 3rd table is used in the join but it doesn't use any
> >> >> > join
> >> >> > key
> >> >> > in WHERE clause.
> >> >> > It may be the cause of the bug.
> >> >> >
> >> >> >
> >> >> > On Thu, Feb 23, 2012 at 9:58 AM, Koichi Suzuki <
> koi...@gm...>
> >> >> > wrote:
> >> >> >>
> >> >> >> I tested more simplified case using 0.9.7 stable.
> >> >> >>
> >> >> >> koichi=# create table t (a int, b int);
> >> >> >> CREATE TABLE
> >> >> >> koichi=# koichi=# insert into t values (1,1);
> >> >> >> INSERT 0 1
> >> >> >> koichi=# insert into t (a) values (2);
> >> >> >> INSERT 0 1
> >> >> >> koichi=# select * from t;
> >> >> >>  a | b
> >> >> >> ---+---
> >> >> >>  1 | 1
> >> >> >>  2 |
> >> >> >> (2 rows)
> >> >> >>
> >> >> >> koichi=# select * from t where b is not null;
> >> >> >>  a | b
> >> >> >> ---+---
> >> >> >>  1 | 1
> >> >> >> (1 row)
> >> >> >>
> >> >> >> koichi=# select * from t where b is null;
> >> >> >>  a | b
> >> >> >> ---+---
> >> >> >>  2 |
> >> >> >> (1 row)
> >> >> >>
> >> >> >> koichi=# create table t2 (c int, d int);
> >> >> >> CREATE TABLE
> >> >> >> koichi=# insert into t2 values (1,1), (2,2);
> >> >> >> INSERT 0 2
> >> >> >> koichi=# select * from t, t2 where a=c;
> >> >> >>  a | b | c | d
> >> >> >> ---+---+---+---
> >> >> >>  1 | 1 | 1 | 1
> >> >> >>  2 |   | 2 | 2
> >> >> >> (2 rows)
> >> >> >>
> >> >> >> koichi=# select * from t, t2 where a=c and b is not null;
> >> >> >>  a | b | c | d
> >> >> >> ---+---+---+---
> >> >> >>  1 | 1 | 1 | 1
> >> >> >> (1 row)
> >> >> >>
> >> >> >> koichi=# select * from t, t2 where a=c and b is null;
> >> >> >>  a | b | c | d
> >> >> >> ---+---+---+---
> >> >> >>  2 |   | 2 | 2
> >> >> >> (1 row)
> >> >> >>
> >> >> >> koichi=# select * from t, t2 where a=c and b is not null and a =
> 1;
> >> >> >>  a | b | c | d
> >> >> >> ---+---+---+---
> >> >> >>  1 | 1 | 1 | 1
> >> >> >> (1 row)
> >> >> >>
> >> >> >> koichi=# select * from t, t2 where a=c and (b is not null and a =
> >> >> >> 1);
> >> >> >>  a | b | c | d
> >> >> >> ---+---+---+---
> >> >> >>  1 | 1 | 1 | 1
> >> >> >> (1 row)
> >> >> >>
> >> >> >> koichi=#
> >> >> >>
> >> >> >> The above looks "IS NULL" and "IS NOT NULL" is scanned correctly
> in
> >> >> >> some case.   Kris, could you let me know insert statement of your
> >> >> >> case
> >> >> >> to reproduce the problem?
> >> >> >>
> >> >> >> Regards;
> >> >> >> ----------
> >> >> >> Koichi Suzuki
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> 2012/2/23 Michael Paquier <mic...@gm...>:
> >> >> >> >
> >> >> >> >
> >> >> >> > On Thu, Feb 23, 2012 at 1:09 AM, Krzysztof Nowicki
> >> >> >> > <krz...@gm...> wrote:
> >> >> >> >>
> >> >> >> >> Hi all,
> >> >> >> >>
> >> >> >> >> I found another problem during testing ver. 0.9.7. Below steps
> to
> >> >> >> >> reproduce:
> >> >> >> >>
> >> >> >> >> CREATE TABLE t1 (id int8, name varchar(80));
> >> >> >> >> CREATE TABLE t2 (id int8, name varchar(80));
> >> >> >> >> CREATE TABLE t3 (id int8, name varchar(80));
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> select * from t1, t2, t3 where t1.id = t3.id AND t3.id is not
> >> >> >> >> null
> >> >> >> >> and
> >> >> >> >> t1.name = 'test';
> >> >> >> >>  id | name | id | name | id | name
> >> >> >> >> ----+------+----+------+----+------
> >> >> >> >> (0 rows)
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not
> >> >> >> >> null
> >> >> >> >> and t1.name = 'test');
> >> >> >> >> ERROR:  could not open relation with OID 0
> >> >> >> >
> >> >> >> > The XC planner looks to be going crazy for such special case.
> >> >> >> > At first sight, I would imagine that the "is not null" type is
> not
> >> >> >> > scanned
> >> >> >> > correctly.
> >> >> >> > --
> >> >> >> > 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
> >> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > 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
> >> >
> >
> >
> >
> >
> > --
> > Best Wishes,
> > Ashutosh Bapat
> > EntepriseDB Corporation
> > The Enterprise Postgres Company
> >
>



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

Thanks.   And you've tested the same query and tables as reported?  My
test is very simple and will not hit the bug.
----------
Koichi Suzuki



2012/2/23 Ashutosh Bapat <ash...@en...>:
> OH, Sorry. By master, I mean the 1.0(devel) master.
>
>
> On Thu, Feb 23, 2012 at 9:54 AM, Koichi Suzuki <koi...@gm...> wrote:
>>
>> What version did you use?   I believe Kris used 0.9.7.   I also tested
>> with 0.9.7.
>>
>>
>> ----------
>> Koichi Suzuki
>>
>>
>>
>> 2012/2/23 Ashutosh Bapat <ash...@en...>:
>> > I ran it with the master, and couldn't reproduce the issue.
>> >
>> >
>> > On Thu, Feb 23, 2012 at 7:04 AM, Koichi Suzuki <koi...@gm...>
>> > wrote:
>> >>
>> >> Yeah, this may be the case.   We should run several test cases
>> >> (against 0.9.7 and master) to determine the cause.
>> >> ----------
>> >> Koichi Suzuki
>> >>
>> >>
>> >>
>> >> 2012/2/23 Michael Paquier <mic...@gm...>:
>> >> > In his case a 3rd table is used in the join but it doesn't use any
>> >> > join
>> >> > key
>> >> > in WHERE clause.
>> >> > It may be the cause of the bug.
>> >> >
>> >> >
>> >> > On Thu, Feb 23, 2012 at 9:58 AM, Koichi Suzuki <koi...@gm...>
>> >> > wrote:
>> >> >>
>> >> >> I tested more simplified case using 0.9.7 stable.
>> >> >>
>> >> >> koichi=# create table t (a int, b int);
>> >> >> CREATE TABLE
>> >> >> koichi=# koichi=# insert into t values (1,1);
>> >> >> INSERT 0 1
>> >> >> koichi=# insert into t (a) values (2);
>> >> >> INSERT 0 1
>> >> >> koichi=# select * from t;
>> >> >>  a | b
>> >> >> ---+---
>> >> >>  1 | 1
>> >> >>  2 |
>> >> >> (2 rows)
>> >> >>
>> >> >> koichi=# select * from t where b is not null;
>> >> >>  a | b
>> >> >> ---+---
>> >> >>  1 | 1
>> >> >> (1 row)
>> >> >>
>> >> >> koichi=# select * from t where b is null;
>> >> >>  a | b
>> >> >> ---+---
>> >> >>  2 |
>> >> >> (1 row)
>> >> >>
>> >> >> koichi=# create table t2 (c int, d int);
>> >> >> CREATE TABLE
>> >> >> koichi=# insert into t2 values (1,1), (2,2);
>> >> >> INSERT 0 2
>> >> >> koichi=# select * from t, t2 where a=c;
>> >> >>  a | b | c | d
>> >> >> ---+---+---+---
>> >> >>  1 | 1 | 1 | 1
>> >> >>  2 |   | 2 | 2
>> >> >> (2 rows)
>> >> >>
>> >> >> koichi=# select * from t, t2 where a=c and b is not null;
>> >> >>  a | b | c | d
>> >> >> ---+---+---+---
>> >> >>  1 | 1 | 1 | 1
>> >> >> (1 row)
>> >> >>
>> >> >> koichi=# select * from t, t2 where a=c and b is null;
>> >> >>  a | b | c | d
>> >> >> ---+---+---+---
>> >> >>  2 |   | 2 | 2
>> >> >> (1 row)
>> >> >>
>> >> >> koichi=# select * from t, t2 where a=c and b is not null and a = 1;
>> >> >>  a | b | c | d
>> >> >> ---+---+---+---
>> >> >>  1 | 1 | 1 | 1
>> >> >> (1 row)
>> >> >>
>> >> >> koichi=# select * from t, t2 where a=c and (b is not null and a =
>> >> >> 1);
>> >> >>  a | b | c | d
>> >> >> ---+---+---+---
>> >> >>  1 | 1 | 1 | 1
>> >> >> (1 row)
>> >> >>
>> >> >> koichi=#
>> >> >>
>> >> >> The above looks "IS NULL" and "IS NOT NULL" is scanned correctly in
>> >> >> some case.   Kris, could you let me know insert statement of your
>> >> >> case
>> >> >> to reproduce the problem?
>> >> >>
>> >> >> Regards;
>> >> >> ----------
>> >> >> Koichi Suzuki
>> >> >>
>> >> >>
>> >> >>
>> >> >> 2012/2/23 Michael Paquier <mic...@gm...>:
>> >> >> >
>> >> >> >
>> >> >> > On Thu, Feb 23, 2012 at 1:09 AM, Krzysztof Nowicki
>> >> >> > <krz...@gm...> wrote:
>> >> >> >>
>> >> >> >> Hi all,
>> >> >> >>
>> >> >> >> I found another problem during testing ver. 0.9.7. Below steps to
>> >> >> >> reproduce:
>> >> >> >>
>> >> >> >> CREATE TABLE t1 (id int8, name varchar(80));
>> >> >> >> CREATE TABLE t2 (id int8, name varchar(80));
>> >> >> >> CREATE TABLE t3 (id int8, name varchar(80));
>> >> >> >>
>> >> >> >>
>> >> >> >> select * from t1, t2, t3 where t1.id = t3.id AND t3.id is not
>> >> >> >> null
>> >> >> >> and
>> >> >> >> t1.name = 'test';
>> >> >> >>  id | name | id | name | id | name
>> >> >> >> ----+------+----+------+----+------
>> >> >> >> (0 rows)
>> >> >> >>
>> >> >> >>
>> >> >> >> select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not
>> >> >> >> null
>> >> >> >> and t1.name = 'test');
>> >> >> >> ERROR:  could not open relation with OID 0
>> >> >> >
>> >> >> > The XC planner looks to be going crazy for such special case.
>> >> >> > At first sight, I would imagine that the "is not null" type is not
>> >> >> > scanned
>> >> >> > correctly.
>> >> >> > --
>> >> >> > 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
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > 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
>> >
>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>

OH, Sorry. By master, I mean the 1.0(devel) master.

On Thu, Feb 23, 2012 at 9:54 AM, Koichi Suzuki <koi...@gm...> wrote:

> What version did you use?   I believe Kris used 0.9.7.   I also tested
> with 0.9.7.
>
>
> ----------
> Koichi Suzuki
>
>
>
> 2012/2/23 Ashutosh Bapat <ash...@en...>:
> > I ran it with the master, and couldn't reproduce the issue.
> >
> >
> > On Thu, Feb 23, 2012 at 7:04 AM, Koichi Suzuki <koi...@gm...>
> wrote:
> >>
> >> Yeah, this may be the case.   We should run several test cases
> >> (against 0.9.7 and master) to determine the cause.
> >> ----------
> >> Koichi Suzuki
> >>
> >>
> >>
> >> 2012/2/23 Michael Paquier <mic...@gm...>:
> >> > In his case a 3rd table is used in the join but it doesn't use any
> join
> >> > key
> >> > in WHERE clause.
> >> > It may be the cause of the bug.
> >> >
> >> >
> >> > On Thu, Feb 23, 2012 at 9:58 AM, Koichi Suzuki <koi...@gm...>
> >> > wrote:
> >> >>
> >> >> I tested more simplified case using 0.9.7 stable.
> >> >>
> >> >> koichi=# create table t (a int, b int);
> >> >> CREATE TABLE
> >> >> koichi=# koichi=# insert into t values (1,1);
> >> >> INSERT 0 1
> >> >> koichi=# insert into t (a) values (2);
> >> >> INSERT 0 1
> >> >> koichi=# select * from t;
> >> >>  a | b
> >> >> ---+---
> >> >>  1 | 1
> >> >>  2 |
> >> >> (2 rows)
> >> >>
> >> >> koichi=# select * from t where b is not null;
> >> >>  a | b
> >> >> ---+---
> >> >>  1 | 1
> >> >> (1 row)
> >> >>
> >> >> koichi=# select * from t where b is null;
> >> >>  a | b
> >> >> ---+---
> >> >>  2 |
> >> >> (1 row)
> >> >>
> >> >> koichi=# create table t2 (c int, d int);
> >> >> CREATE TABLE
> >> >> koichi=# insert into t2 values (1,1), (2,2);
> >> >> INSERT 0 2
> >> >> koichi=# select * from t, t2 where a=c;
> >> >>  a | b | c | d
> >> >> ---+---+---+---
> >> >>  1 | 1 | 1 | 1
> >> >>  2 |   | 2 | 2
> >> >> (2 rows)
> >> >>
> >> >> koichi=# select * from t, t2 where a=c and b is not null;
> >> >>  a | b | c | d
> >> >> ---+---+---+---
> >> >>  1 | 1 | 1 | 1
> >> >> (1 row)
> >> >>
> >> >> koichi=# select * from t, t2 where a=c and b is null;
> >> >>  a | b | c | d
> >> >> ---+---+---+---
> >> >>  2 |   | 2 | 2
> >> >> (1 row)
> >> >>
> >> >> koichi=# select * from t, t2 where a=c and b is not null and a = 1;
> >> >>  a | b | c | d
> >> >> ---+---+---+---
> >> >>  1 | 1 | 1 | 1
> >> >> (1 row)
> >> >>
> >> >> koichi=# select * from t, t2 where a=c and (b is not null and a = 1);
> >> >>  a | b | c | d
> >> >> ---+---+---+---
> >> >>  1 | 1 | 1 | 1
> >> >> (1 row)
> >> >>
> >> >> koichi=#
> >> >>
> >> >> The above looks "IS NULL" and "IS NOT NULL" is scanned correctly in
> >> >> some case.   Kris, could you let me know insert statement of your
> case
> >> >> to reproduce the problem?
> >> >>
> >> >> Regards;
> >> >> ----------
> >> >> Koichi Suzuki
> >> >>
> >> >>
> >> >>
> >> >> 2012/2/23 Michael Paquier <mic...@gm...>:
> >> >> >
> >> >> >
> >> >> > On Thu, Feb 23, 2012 at 1:09 AM, Krzysztof Nowicki
> >> >> > <krz...@gm...> wrote:
> >> >> >>
> >> >> >> Hi all,
> >> >> >>
> >> >> >> I found another problem during testing ver. 0.9.7. Below steps to
> >> >> >> reproduce:
> >> >> >>
> >> >> >> CREATE TABLE t1 (id int8, name varchar(80));
> >> >> >> CREATE TABLE t2 (id int8, name varchar(80));
> >> >> >> CREATE TABLE t3 (id int8, name varchar(80));
> >> >> >>
> >> >> >>
> >> >> >> select * from t1, t2, t3 where t1.id = t3.id AND t3.id is not
> null
> >> >> >> and
> >> >> >> t1.name = 'test';
> >> >> >>  id | name | id | name | id | name
> >> >> >> ----+------+----+------+----+------
> >> >> >> (0 rows)
> >> >> >>
> >> >> >>
> >> >> >> select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not
> null
> >> >> >> and t1.name = 'test');
> >> >> >> ERROR:  could not open relation with OID 0
> >> >> >
> >> >> > The XC planner looks to be going crazy for such special case.
> >> >> > At first sight, I would imagine that the "is not null" type is not
> >> >> > scanned
> >> >> > correctly.
> >> >> > --
> >> >> > 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
> >> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > 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
> >
>



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

What version did you use?   I believe Kris used 0.9.7.   I also tested
with 0.9.7.


----------
Koichi Suzuki



2012/2/23 Ashutosh Bapat <ash...@en...>:
> I ran it with the master, and couldn't reproduce the issue.
>
>
> On Thu, Feb 23, 2012 at 7:04 AM, Koichi Suzuki <koi...@gm...> wrote:
>>
>> Yeah, this may be the case.   We should run several test cases
>> (against 0.9.7 and master) to determine the cause.
>> ----------
>> Koichi Suzuki
>>
>>
>>
>> 2012/2/23 Michael Paquier <mic...@gm...>:
>> > In his case a 3rd table is used in the join but it doesn't use any join
>> > key
>> > in WHERE clause.
>> > It may be the cause of the bug.
>> >
>> >
>> > On Thu, Feb 23, 2012 at 9:58 AM, Koichi Suzuki <koi...@gm...>
>> > wrote:
>> >>
>> >> I tested more simplified case using 0.9.7 stable.
>> >>
>> >> koichi=# create table t (a int, b int);
>> >> CREATE TABLE
>> >> koichi=# koichi=# insert into t values (1,1);
>> >> INSERT 0 1
>> >> koichi=# insert into t (a) values (2);
>> >> INSERT 0 1
>> >> koichi=# select * from t;
>> >>  a | b
>> >> ---+---
>> >>  1 | 1
>> >>  2 |
>> >> (2 rows)
>> >>
>> >> koichi=# select * from t where b is not null;
>> >>  a | b
>> >> ---+---
>> >>  1 | 1
>> >> (1 row)
>> >>
>> >> koichi=# select * from t where b is null;
>> >>  a | b
>> >> ---+---
>> >>  2 |
>> >> (1 row)
>> >>
>> >> koichi=# create table t2 (c int, d int);
>> >> CREATE TABLE
>> >> koichi=# insert into t2 values (1,1), (2,2);
>> >> INSERT 0 2
>> >> koichi=# select * from t, t2 where a=c;
>> >>  a | b | c | d
>> >> ---+---+---+---
>> >>  1 | 1 | 1 | 1
>> >>  2 |   | 2 | 2
>> >> (2 rows)
>> >>
>> >> koichi=# select * from t, t2 where a=c and b is not null;
>> >>  a | b | c | d
>> >> ---+---+---+---
>> >>  1 | 1 | 1 | 1
>> >> (1 row)
>> >>
>> >> koichi=# select * from t, t2 where a=c and b is null;
>> >>  a | b | c | d
>> >> ---+---+---+---
>> >>  2 |   | 2 | 2
>> >> (1 row)
>> >>
>> >> koichi=# select * from t, t2 where a=c and b is not null and a = 1;
>> >>  a | b | c | d
>> >> ---+---+---+---
>> >>  1 | 1 | 1 | 1
>> >> (1 row)
>> >>
>> >> koichi=# select * from t, t2 where a=c and (b is not null and a = 1);
>> >>  a | b | c | d
>> >> ---+---+---+---
>> >>  1 | 1 | 1 | 1
>> >> (1 row)
>> >>
>> >> koichi=#
>> >>
>> >> The above looks "IS NULL" and "IS NOT NULL" is scanned correctly in
>> >> some case.   Kris, could you let me know insert statement of your case
>> >> to reproduce the problem?
>> >>
>> >> Regards;
>> >> ----------
>> >> Koichi Suzuki
>> >>
>> >>
>> >>
>> >> 2012/2/23 Michael Paquier <mic...@gm...>:
>> >> >
>> >> >
>> >> > On Thu, Feb 23, 2012 at 1:09 AM, Krzysztof Nowicki
>> >> > <krz...@gm...> wrote:
>> >> >>
>> >> >> Hi all,
>> >> >>
>> >> >> I found another problem during testing ver. 0.9.7. Below steps to
>> >> >> reproduce:
>> >> >>
>> >> >> CREATE TABLE t1 (id int8, name varchar(80));
>> >> >> CREATE TABLE t2 (id int8, name varchar(80));
>> >> >> CREATE TABLE t3 (id int8, name varchar(80));
>> >> >>
>> >> >>
>> >> >> select * from t1, t2, t3 where t1.id = t3.id AND t3.id is not null
>> >> >> and
>> >> >> t1.name = 'test';
>> >> >>  id | name | id | name | id | name
>> >> >> ----+------+----+------+----+------
>> >> >> (0 rows)
>> >> >>
>> >> >>
>> >> >> select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not null
>> >> >> and t1.name = 'test');
>> >> >> ERROR:  could not open relation with OID 0
>> >> >
>> >> > The XC planner looks to be going crazy for such special case.
>> >> > At first sight, I would imagine that the "is not null" type is not
>> >> > scanned
>> >> > correctly.
>> >> > --
>> >> > 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
>> >> >
>> >
>> >
>> >
>> >
>> > --
>> > 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 ran it with the master, and couldn't reproduce the issue.

On Thu, Feb 23, 2012 at 7:04 AM, Koichi Suzuki <koi...@gm...> wrote:

> Yeah, this may be the case.   We should run several test cases
> (against 0.9.7 and master) to determine the cause.
> ----------
> Koichi Suzuki
>
>
>
> 2012/2/23 Michael Paquier <mic...@gm...>:
> > In his case a 3rd table is used in the join but it doesn't use any join
> key
> > in WHERE clause.
> > It may be the cause of the bug.
> >
> >
> > On Thu, Feb 23, 2012 at 9:58 AM, Koichi Suzuki <koi...@gm...>
> wrote:
> >>
> >> I tested more simplified case using 0.9.7 stable.
> >>
> >> koichi=# create table t (a int, b int);
> >> CREATE TABLE
> >> koichi=# koichi=# insert into t values (1,1);
> >> INSERT 0 1
> >> koichi=# insert into t (a) values (2);
> >> INSERT 0 1
> >> koichi=# select * from t;
> >>  a | b
> >> ---+---
> >>  1 | 1
> >>  2 |
> >> (2 rows)
> >>
> >> koichi=# select * from t where b is not null;
> >>  a | b
> >> ---+---
> >>  1 | 1
> >> (1 row)
> >>
> >> koichi=# select * from t where b is null;
> >>  a | b
> >> ---+---
> >>  2 |
> >> (1 row)
> >>
> >> koichi=# create table t2 (c int, d int);
> >> CREATE TABLE
> >> koichi=# insert into t2 values (1,1), (2,2);
> >> INSERT 0 2
> >> koichi=# select * from t, t2 where a=c;
> >>  a | b | c | d
> >> ---+---+---+---
> >>  1 | 1 | 1 | 1
> >>  2 |   | 2 | 2
> >> (2 rows)
> >>
> >> koichi=# select * from t, t2 where a=c and b is not null;
> >>  a | b | c | d
> >> ---+---+---+---
> >>  1 | 1 | 1 | 1
> >> (1 row)
> >>
> >> koichi=# select * from t, t2 where a=c and b is null;
> >>  a | b | c | d
> >> ---+---+---+---
> >>  2 |   | 2 | 2
> >> (1 row)
> >>
> >> koichi=# select * from t, t2 where a=c and b is not null and a = 1;
> >>  a | b | c | d
> >> ---+---+---+---
> >>  1 | 1 | 1 | 1
> >> (1 row)
> >>
> >> koichi=# select * from t, t2 where a=c and (b is not null and a = 1);
> >>  a | b | c | d
> >> ---+---+---+---
> >>  1 | 1 | 1 | 1
> >> (1 row)
> >>
> >> koichi=#
> >>
> >> The above looks "IS NULL" and "IS NOT NULL" is scanned correctly in
> >> some case.   Kris, could you let me know insert statement of your case
> >> to reproduce the problem?
> >>
> >> Regards;
> >> ----------
> >> Koichi Suzuki
> >>
> >>
> >>
> >> 2012/2/23 Michael Paquier <mic...@gm...>:
> >> >
> >> >
> >> > On Thu, Feb 23, 2012 at 1:09 AM, Krzysztof Nowicki
> >> > <krz...@gm...> wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> I found another problem during testing ver. 0.9.7. Below steps to
> >> >> reproduce:
> >> >>
> >> >> CREATE TABLE t1 (id int8, name varchar(80));
> >> >> CREATE TABLE t2 (id int8, name varchar(80));
> >> >> CREATE TABLE t3 (id int8, name varchar(80));
> >> >>
> >> >>
> >> >> select * from t1, t2, t3 where t1.id = t3.id AND t3.id is not null
> and
> >> >> t1.name = 'test';
> >> >>  id | name | id | name | id | name
> >> >> ----+------+----+------+----+------
> >> >> (0 rows)
> >> >>
> >> >>
> >> >> select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not null
> >> >> and t1.name = 'test');
> >> >> ERROR:  could not open relation with OID 0
> >> >
> >> > The XC planner looks to be going crazy for such special case.
> >> > At first sight, I would imagine that the "is not null" type is not
> >> > scanned
> >> > correctly.
> >> > --
> >> > 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
> >> >
> >
> >
> >
> >
> > --
> > 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

Yeah, this may be the case.   We should run several test cases
(against 0.9.7 and master) to determine the cause.
----------
Koichi Suzuki



2012/2/23 Michael Paquier <mic...@gm...>:
> In his case a 3rd table is used in the join but it doesn't use any join key
> in WHERE clause.
> It may be the cause of the bug.
>
>
> On Thu, Feb 23, 2012 at 9:58 AM, Koichi Suzuki <koi...@gm...> wrote:
>>
>> I tested more simplified case using 0.9.7 stable.
>>
>> koichi=# create table t (a int, b int);
>> CREATE TABLE
>> koichi=# koichi=# insert into t values (1,1);
>> INSERT 0 1
>> koichi=# insert into t (a) values (2);
>> INSERT 0 1
>> koichi=# select * from t;
>>  a | b
>> ---+---
>>  1 | 1
>>  2 |
>> (2 rows)
>>
>> koichi=# select * from t where b is not null;
>>  a | b
>> ---+---
>>  1 | 1
>> (1 row)
>>
>> koichi=# select * from t where b is null;
>>  a | b
>> ---+---
>>  2 |
>> (1 row)
>>
>> koichi=# create table t2 (c int, d int);
>> CREATE TABLE
>> koichi=# insert into t2 values (1,1), (2,2);
>> INSERT 0 2
>> koichi=# select * from t, t2 where a=c;
>>  a | b | c | d
>> ---+---+---+---
>>  1 | 1 | 1 | 1
>>  2 |   | 2 | 2
>> (2 rows)
>>
>> koichi=# select * from t, t2 where a=c and b is not null;
>>  a | b | c | d
>> ---+---+---+---
>>  1 | 1 | 1 | 1
>> (1 row)
>>
>> koichi=# select * from t, t2 where a=c and b is null;
>>  a | b | c | d
>> ---+---+---+---
>>  2 |   | 2 | 2
>> (1 row)
>>
>> koichi=# select * from t, t2 where a=c and b is not null and a = 1;
>>  a | b | c | d
>> ---+---+---+---
>>  1 | 1 | 1 | 1
>> (1 row)
>>
>> koichi=# select * from t, t2 where a=c and (b is not null and a = 1);
>>  a | b | c | d
>> ---+---+---+---
>>  1 | 1 | 1 | 1
>> (1 row)
>>
>> koichi=#
>>
>> The above looks "IS NULL" and "IS NOT NULL" is scanned correctly in
>> some case.   Kris, could you let me know insert statement of your case
>> to reproduce the problem?
>>
>> Regards;
>> ----------
>> Koichi Suzuki
>>
>>
>>
>> 2012/2/23 Michael Paquier <mic...@gm...>:
>> >
>> >
>> > On Thu, Feb 23, 2012 at 1:09 AM, Krzysztof Nowicki
>> > <krz...@gm...> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I found another problem during testing ver. 0.9.7. Below steps to
>> >> reproduce:
>> >>
>> >> CREATE TABLE t1 (id int8, name varchar(80));
>> >> CREATE TABLE t2 (id int8, name varchar(80));
>> >> CREATE TABLE t3 (id int8, name varchar(80));
>> >>
>> >>
>> >> select * from t1, t2, t3 where t1.id = t3.id AND t3.id is not null and
>> >> t1.name = 'test';
>> >>  id | name | id | name | id | name
>> >> ----+------+----+------+----+------
>> >> (0 rows)
>> >>
>> >>
>> >> select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not null
>> >> and t1.name = 'test');
>> >> ERROR:  could not open relation with OID 0
>> >
>> > The XC planner looks to be going crazy for such special case.
>> > At first sight, I would imagine that the "is not null" type is not
>> > scanned
>> > correctly.
>> > --
>> > 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
>> >
>
>
>
>
> --
> Michael Paquier
> http://michael.otacoo.com

In his case a 3rd table is used in the join but it doesn't use any join key
in WHERE clause.
It may be the cause of the bug.

On Thu, Feb 23, 2012 at 9:58 AM, Koichi Suzuki <koi...@gm...> wrote:

> I tested more simplified case using 0.9.7 stable.
>
> koichi=# create table t (a int, b int);
> CREATE TABLE
> koichi=# koichi=# insert into t values (1,1);
> INSERT 0 1
> koichi=# insert into t (a) values (2);
> INSERT 0 1
> koichi=# select * from t;
>  a | b
> ---+---
>  1 | 1
>  2 |
> (2 rows)
>
> koichi=# select * from t where b is not null;
>  a | b
> ---+---
>  1 | 1
> (1 row)
>
> koichi=# select * from t where b is null;
>  a | b
> ---+---
>  2 |
> (1 row)
>
> koichi=# create table t2 (c int, d int);
> CREATE TABLE
> koichi=# insert into t2 values (1,1), (2,2);
> INSERT 0 2
> koichi=# select * from t, t2 where a=c;
>  a | b | c | d
> ---+---+---+---
>  1 | 1 | 1 | 1
>  2 |   | 2 | 2
> (2 rows)
>
> koichi=# select * from t, t2 where a=c and b is not null;
>  a | b | c | d
> ---+---+---+---
>  1 | 1 | 1 | 1
> (1 row)
>
> koichi=# select * from t, t2 where a=c and b is null;
>  a | b | c | d
> ---+---+---+---
>  2 |   | 2 | 2
> (1 row)
>
> koichi=# select * from t, t2 where a=c and b is not null and a = 1;
>  a | b | c | d
> ---+---+---+---
>  1 | 1 | 1 | 1
> (1 row)
>
> koichi=# select * from t, t2 where a=c and (b is not null and a = 1);
>  a | b | c | d
> ---+---+---+---
>  1 | 1 | 1 | 1
> (1 row)
>
> koichi=#
>
> The above looks "IS NULL" and "IS NOT NULL" is scanned correctly in
> some case.   Kris, could you let me know insert statement of your case
> to reproduce the problem?
>
> Regards;
> ----------
> Koichi Suzuki
>
>
>
> 2012/2/23 Michael Paquier <mic...@gm...>:
> >
> >
> > On Thu, Feb 23, 2012 at 1:09 AM, Krzysztof Nowicki
> > <krz...@gm...> wrote:
> >>
> >> Hi all,
> >>
> >> I found another problem during testing ver. 0.9.7. Below steps to
> >> reproduce:
> >>
> >> CREATE TABLE t1 (id int8, name varchar(80));
> >> CREATE TABLE t2 (id int8, name varchar(80));
> >> CREATE TABLE t3 (id int8, name varchar(80));
> >>
> >>
> >> select * from t1, t2, t3 where t1.id = t3.id AND t3.id is not null and
> >> t1.name = 'test';
> >>  id | name | id | name | id | name
> >> ----+------+----+------+----+------
> >> (0 rows)
> >>
> >>
> >> select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not null
> >> and t1.name = 'test');
> >> ERROR:  could not open relation with OID 0
> >
> > The XC planner looks to be going crazy for such special case.
> > At first sight, I would imagine that the "is not null" type is not
> scanned
> > correctly.
> > --
> > 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
> >
>



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

I tested more simplified case using 0.9.7 stable.

koichi=# create table t (a int, b int);
CREATE TABLE
koichi=# koichi=# insert into t values (1,1);
INSERT 0 1
koichi=# insert into t (a) values (2);
INSERT 0 1
koichi=# select * from t;
 a | b
---+---
 1 | 1
 2 |
(2 rows)

koichi=# select * from t where b is not null;
 a | b
---+---
 1 | 1
(1 row)

koichi=# select * from t where b is null;
 a | b
---+---
 2 |
(1 row)

koichi=# create table t2 (c int, d int);
CREATE TABLE
koichi=# insert into t2 values (1,1), (2,2);
INSERT 0 2
koichi=# select * from t, t2 where a=c;
 a | b | c | d
---+---+---+---
 1 | 1 | 1 | 1
 2 |   | 2 | 2
(2 rows)

koichi=# select * from t, t2 where a=c and b is not null;
 a | b | c | d
---+---+---+---
 1 | 1 | 1 | 1
(1 row)

koichi=# select * from t, t2 where a=c and b is null;
 a | b | c | d
---+---+---+---
 2 |   | 2 | 2
(1 row)

koichi=# select * from t, t2 where a=c and b is not null and a = 1;
 a | b | c | d
---+---+---+---
 1 | 1 | 1 | 1
(1 row)

koichi=# select * from t, t2 where a=c and (b is not null and a = 1);
 a | b | c | d
---+---+---+---
 1 | 1 | 1 | 1
(1 row)

koichi=#

The above looks "IS NULL" and "IS NOT NULL" is scanned correctly in
some case.   Kris, could you let me know insert statement of your case
to reproduce the problem?

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



2012/2/23 Michael Paquier <mic...@gm...>:
>
>
> On Thu, Feb 23, 2012 at 1:09 AM, Krzysztof Nowicki
> <krz...@gm...> wrote:
>>
>> Hi all,
>>
>> I found another problem during testing ver. 0.9.7. Below steps to
>> reproduce:
>>
>> CREATE TABLE t1 (id int8, name varchar(80));
>> CREATE TABLE t2 (id int8, name varchar(80));
>> CREATE TABLE t3 (id int8, name varchar(80));
>>
>>
>> select * from t1, t2, t3 where t1.id = t3.id AND t3.id is not null and
>> t1.name = 'test';
>>  id | name | id | name | id | name
>> ----+------+----+------+----+------
>> (0 rows)
>>
>>
>> select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not null
>> and t1.name = 'test');
>> ERROR:  could not open relation with OID 0
>
> The XC planner looks to be going crazy for such special case.
> At first sight, I would imagine that the "is not null" type is not scanned
> correctly.
> --
> 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 Thu, Feb 23, 2012 at 1:09 AM, Krzysztof Nowicki <
krz...@gm...> wrote:

> Hi all,
>
> I found another problem during testing ver. 0.9.7. Below steps to
> reproduce:
>
> CREATE TABLE t1 (id int8, name varchar(80));
> CREATE TABLE t2 (id int8, name varchar(80));
> CREATE TABLE t3 (id int8, name varchar(80));
>
>
> select * from t1, t2, t3 where t1.id = t3.id AND t3.id is not null and
> t1.name = 'test';
>  id | name | id | name | id | name
> ----+------+----+------+----+------
> (0 rows)
>
>
> select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not null
> and t1.name = 'test');
> ERROR:  could not open relation with OID 0
>
The XC planner looks to be going crazy for such special case.
At first sight, I would imagine that the "is not null" type is not scanned
correctly.
-- 
Michael Paquier
http://michael.otacoo.com

Hi all,

I found another problem during testing ver. 0.9.7. Below steps to reproduce:

CREATE TABLE t1 (id int8, name varchar(80));
CREATE TABLE t2 (id int8, name varchar(80));
CREATE TABLE t3 (id int8, name varchar(80));


select * from t1, t2, t3 where t1.id = t3.id AND t3.id is not null and
t1.name = 'test';
 id | name | id | name | id | name
----+------+----+------+----+------
(0 rows)


select * from t1, t2, t3 where t1.id = t3.id AND (t3.id is not null
and t1.name = 'test');
ERROR:  could not open relation with OID 0

Best Regards,

Kris N.

Yes, it would be a good candidate. As current xc uses fixed-size cluster, this has no impact yet, but in case of mode addition/deletion?

On 2012/02/22, at 14:13, Pavan Deolasee <pav...@en...> wrote:

> On Wed, Feb 22, 2012 at 10:20 AM, Koichi Suzuki <koi...@gm...> wrote:
>> 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.
>> 
> 
> We can also use PGXCNodeId and fetch it from the remote node along
> with CTID. So the query would look like,
> 
> SELECT col1, col2, CTID, get_nodeid() FROM remote_tab;
> 
> At some point, we should seriously
> 
> -- 
> Pavan Deolasee
> EnterpriseDB http://www.enterprisedb.com

On Wed, Feb 22, 2012 at 10:20 AM, Koichi Suzuki <koi...@gm...> wrote:
> 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.
>

We can also use PGXCNodeId and fetch it from the remote node along
with CTID. So the query would look like,

SELECT col1, col2, CTID, get_nodeid() FROM remote_tab;

At some point, we should seriously

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

Node oid itself is not consistent among nodes. Node name string is the only consistent data in the cluster able to manage this ctid extension.

On 2012/02/22, at 13:50, Koichi Suzuki <koi...@gm...> wrote:

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