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

Looks like we cannot do away with the tuplestore that easily.

Especially if the remote query is an inner scan node, then it makes sense
to materialize and store the rows in the tuplestore for subsequent rescans.
However this should have been based on row statistics. If the query brings
in a lot of rows, then we are sure to run out of memory like some reports
that we have seen.

Additionally, ISTM, that the tuplestore should only be used for inner
nodes. There's no need to store outer nodes in tuplestores. Also if it's a
single SELECT query, then there's no need to use tuplestore at all as well.

Looks like if we can pass hints during plan creation as to whether the
remote scan is part of a join (and is inner node) or not, then accordingly
decision can be taken to materialize into the tuplestore.

Regards,
Nikhils

On Thu, Aug 15, 2013 at 10:43 PM, Nikhil Sontakke <ni...@st...>wrote:

> Looks like my theory was wrong, make installcheck is giving more errors
> with this patch applied. Will have to look at a different solution..
>
> Regards,
> Nikhils
>
>
> On Thu, Aug 15, 2013 at 2:11 PM, Nikhil Sontakke <ni...@st...>wrote:
>
>> So, I looked at this code carefully and ISTM, that because of the way we
>> fetch the data from the connections and return it immediately inside
>> RemoteQueryNext, storing it in the tuplestore using tuplestore_puttupleslot
>> is NOT required at all.
>>
>> So, I have removed the call to tuplestore_puttupleslot and things seem to
>> be ok for me. I guess we should do a FULL test run with this patch just to
>> ensure that it does not cause issues in any scenarios.
>>
>> A careful look by new set of eyes will help here. I think, if there are
>> no issues, this plugs a major leak in the RemoteQuery code path which is
>> almost always used in our case.
>>
>> Regards,
>> Nikhils
>>
>>
>> On Wed, Aug 14, 2013 at 7:05 PM, Nikhil Sontakke <ni...@st...>wrote:
>>
>>> Using a tuplestore for data coming from RemoteQuery is kinda wrong and
>>> that's what has introduced this issue. Looks like just changing the memory
>>> context will not work as it interferes with the other functioning of the
>>> tuplestore :-|
>>>
>>> Regards,
>>> Nikhils
>>>
>>>
>>>
>>> On Wed, Aug 14, 2013 at 3:07 PM, Ashutosh Bapat <
>>> ash...@en...> wrote:
>>>
>>>> Yes, that's correct.
>>>>
>>>> My patch was not intended to fix this. This was added while fixing a
>>>> bug for parameterised quals on RemoteQuery I think. Check commits by Amit
>>>> in this area.
>>>>
>>>>
>>>> On Wed, Aug 14, 2013 at 3:03 PM, Nikhil Sontakke <ni...@st...>wrote:
>>>>
>>>>> Yeah, but AFAICS, even 1.1 (and head) *still* has a leak in it.
>>>>>
>>>>> Here's the snippet from RemoteQueryNext:
>>>>>
>>>>> if (tuplestorestate && !TupIsNull(scanslot))
>>>>>                     tuplestore_puttupleslot(tuplestorestate, scanslot);
>>>>>
>>>>> I printed the current memory context inside this function, it is
>>>>> ""ExecutorState". This means that the tuple will stay around till the query
>>>>> is executing in its entirety! For large COPY queries this is bound to cause
>>>>> issues as is also reported by Hitoshi san on another thread.
>>>>>
>>>>> I propose that in RemoteQueryNext, before calling the
>>>>> tuplestore_puttupleslot we switch into
>>>>> scan_node->ps.ps_ExprContext's ecxt_per_tuple_memory context. It will
>>>>> get reset, when the next tuple has to be returned to the caller and the
>>>>> leak will be curtailed. Thoughts?
>>>>>
>>>>> Regards,
>>>>> Nikhils
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 14, 2013 at 11:33 AM, Ashutosh Bapat <
>>>>> ash...@en...> wrote:
>>>>>
>>>>>> There has been an overhaul in the planner (and corresponding parts of
>>>>>> executor) in 1.1, so it would be better if they move to 1.1 after GA.
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 14, 2013 at 10:54 AM, Nikhil Sontakke <
>>>>>> ni...@st...> wrote:
>>>>>>
>>>>>>> Ah, I see.
>>>>>>>
>>>>>>> I was looking at REL_1_0 sources.
>>>>>>>
>>>>>>> There are people out there using REL_1_0 as well.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Nikhils
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 13, 2013 at 9:52 AM, Ashutosh Bapat <
>>>>>>> ash...@en...> wrote:
>>>>>>>
>>>>>>>> It should be part of 1.1 as well. It was done to support projection
>>>>>>>> out of RemoteQuery node.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Aug 13, 2013 at 7:17 AM, Nikhil Sontakke <
>>>>>>>> ni...@st...> wrote:
>>>>>>>>
>>>>>>>>> Hi Ashutosh,
>>>>>>>>>
>>>>>>>>> I guess you have changed it in pgxc head? I was looking at 103 and
>>>>>>>>> 11 branches and saw this. In that even ExecRemoteQuery seems to have an
>>>>>>>>> issue wherein it's not using the appropriate context.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Nikhils
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>> On Aug 12, 2013, at 9:54 AM, Ashutosh Bapat <
>>>>>>>>> ash...@en...> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Welcome to the mess ;) and enjoy junk food.
>>>>>>>>>
>>>>>>>>> Sometime back, I have changed ExecRemoteQuery to be called in the
>>>>>>>>> same fashion as other Scan nodes. So, you will see ExecRemoteQuery calling
>>>>>>>>> ExecScan with RemoteQueryNext as the iterator. So, I assume your comment
>>>>>>>>> pertains to RemoteQueryNext and its minions and not ExecRemoteQuery per say!
>>>>>>>>>
>>>>>>>>> This code needs a lot of rework, removing duplications, using
>>>>>>>>> proper way of materialisation, central response handler and error handler
>>>>>>>>> etc. If we clean up this code, some improvements in planner (like using
>>>>>>>>> MergeAppend plan) for Sort, will be possible. Regarding materialisation,
>>>>>>>>> the code uses a linked list for materialising the rows from datanodes (in
>>>>>>>>> case the same connection needs to be given to other remote query node),
>>>>>>>>> which must be eating a lot of performance. Instead we should be using some
>>>>>>>>> kind of tuplestore there. We actually use tuplestore (as well) in the
>>>>>>>>> RemoteQuery node; the same method can be used.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Aug 10, 2013 at 10:48 PM, Nikhil Sontakke <
>>>>>>>>> ni...@st...> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Have a Query about ExecRemoteQuery.
>>>>>>>>>>
>>>>>>>>>> The logic seems to have been modeled after ExecMaterial. ISTM,
>>>>>>>>>> that it should have been modeled after ExecScan because we fetch tuples,
>>>>>>>>>> and those which match the qual should be sent up. ExecMaterial is for
>>>>>>>>>> materializing and collecting and storing tuples.
>>>>>>>>>>
>>>>>>>>>> Can anyone explain? The reason for asking this is I am suspecting
>>>>>>>>>> a big memory leak in this code path. We are not using any expression
>>>>>>>>>> context nor we are freeing up tuples as we scan for the one which qualifies.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Nikhils
>>>>>>>>>> --
>>>>>>>>>> StormDB - http://www.stormdb.com
>>>>>>>>>> The Database Cloud
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>>>>>>>>> It's a free troubleshooting tool designed for production.
>>>>>>>>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>>>>>>>>> Download for free and get started troubleshooting in minutes.
>>>>>>>>>>
>>>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Postgres-xc-developers mailing list
>>>>>>>>>> Pos...@li...
>>>>>>>>>>
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best Wishes,
>>>>>>>>> Ashutosh Bapat
>>>>>>>>> EntepriseDB Corporation
>>>>>>>>> The Postgres Database Company
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best Wishes,
>>>>>>>> Ashutosh Bapat
>>>>>>>> EntepriseDB Corporation
>>>>>>>> The Postgres Database Company
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> StormDB - http://www.stormdb.com
>>>>>>> The Database Cloud
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best Wishes,
>>>>>> Ashutosh Bapat
>>>>>> EntepriseDB Corporation
>>>>>> The Postgres Database Company
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> StormDB - http://www.stormdb.com
>>>>> The Database Cloud
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Wishes,
>>>> Ashutosh Bapat
>>>> EntepriseDB Corporation
>>>> The Postgres Database Company
>>>>
>>>
>>>
>>>
>>> --
>>> StormDB - http://www.stormdb.com
>>> The Database Cloud
>>>
>>
>>
>>
>> --
>> StormDB - http://www.stormdb.com
>> The Database Cloud
>>
>
>
>
> --
> StormDB - http://www.stormdb.com
> The Database Cloud
>



-- 
StormDB - http://www.stormdb.com
The Database Cloud

Looks like my theory was wrong, make installcheck is giving more errors
with this patch applied. Will have to look at a different solution..

Regards,
Nikhils

On Thu, Aug 15, 2013 at 2:11 PM, Nikhil Sontakke <ni...@st...>wrote:

> So, I looked at this code carefully and ISTM, that because of the way we
> fetch the data from the connections and return it immediately inside
> RemoteQueryNext, storing it in the tuplestore using tuplestore_puttupleslot
> is NOT required at all.
>
> So, I have removed the call to tuplestore_puttupleslot and things seem to
> be ok for me. I guess we should do a FULL test run with this patch just to
> ensure that it does not cause issues in any scenarios.
>
> A careful look by new set of eyes will help here. I think, if there are no
> issues, this plugs a major leak in the RemoteQuery code path which is
> almost always used in our case.
>
> Regards,
> Nikhils
>
>
> On Wed, Aug 14, 2013 at 7:05 PM, Nikhil Sontakke <ni...@st...>wrote:
>
>> Using a tuplestore for data coming from RemoteQuery is kinda wrong and
>> that's what has introduced this issue. Looks like just changing the memory
>> context will not work as it interferes with the other functioning of the
>> tuplestore :-|
>>
>> Regards,
>> Nikhils
>>
>>
>>
>> On Wed, Aug 14, 2013 at 3:07 PM, Ashutosh Bapat <
>> ash...@en...> wrote:
>>
>>> Yes, that's correct.
>>>
>>> My patch was not intended to fix this. This was added while fixing a bug
>>> for parameterised quals on RemoteQuery I think. Check commits by Amit in
>>> this area.
>>>
>>>
>>> On Wed, Aug 14, 2013 at 3:03 PM, Nikhil Sontakke <ni...@st...>wrote:
>>>
>>>> Yeah, but AFAICS, even 1.1 (and head) *still* has a leak in it.
>>>>
>>>> Here's the snippet from RemoteQueryNext:
>>>>
>>>> if (tuplestorestate && !TupIsNull(scanslot))
>>>>                     tuplestore_puttupleslot(tuplestorestate, scanslot);
>>>>
>>>> I printed the current memory context inside this function, it is
>>>> ""ExecutorState". This means that the tuple will stay around till the query
>>>> is executing in its entirety! For large COPY queries this is bound to cause
>>>> issues as is also reported by Hitoshi san on another thread.
>>>>
>>>> I propose that in RemoteQueryNext, before calling the
>>>> tuplestore_puttupleslot we switch into
>>>> scan_node->ps.ps_ExprContext's ecxt_per_tuple_memory context. It will
>>>> get reset, when the next tuple has to be returned to the caller and the
>>>> leak will be curtailed. Thoughts?
>>>>
>>>> Regards,
>>>> Nikhils
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Aug 14, 2013 at 11:33 AM, Ashutosh Bapat <
>>>> ash...@en...> wrote:
>>>>
>>>>> There has been an overhaul in the planner (and corresponding parts of
>>>>> executor) in 1.1, so it would be better if they move to 1.1 after GA.
>>>>>
>>>>>
>>>>> On Wed, Aug 14, 2013 at 10:54 AM, Nikhil Sontakke <ni...@st...
>>>>> > wrote:
>>>>>
>>>>>> Ah, I see.
>>>>>>
>>>>>> I was looking at REL_1_0 sources.
>>>>>>
>>>>>> There are people out there using REL_1_0 as well.
>>>>>>
>>>>>> Regards,
>>>>>> Nikhils
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 13, 2013 at 9:52 AM, Ashutosh Bapat <
>>>>>> ash...@en...> wrote:
>>>>>>
>>>>>>> It should be part of 1.1 as well. It was done to support projection
>>>>>>> out of RemoteQuery node.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 13, 2013 at 7:17 AM, Nikhil Sontakke <
>>>>>>> ni...@st...> wrote:
>>>>>>>
>>>>>>>> Hi Ashutosh,
>>>>>>>>
>>>>>>>> I guess you have changed it in pgxc head? I was looking at 103 and
>>>>>>>> 11 branches and saw this. In that even ExecRemoteQuery seems to have an
>>>>>>>> issue wherein it's not using the appropriate context.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Nikhils
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Aug 12, 2013, at 9:54 AM, Ashutosh Bapat <
>>>>>>>> ash...@en...> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Welcome to the mess ;) and enjoy junk food.
>>>>>>>>
>>>>>>>> Sometime back, I have changed ExecRemoteQuery to be called in the
>>>>>>>> same fashion as other Scan nodes. So, you will see ExecRemoteQuery calling
>>>>>>>> ExecScan with RemoteQueryNext as the iterator. So, I assume your comment
>>>>>>>> pertains to RemoteQueryNext and its minions and not ExecRemoteQuery per say!
>>>>>>>>
>>>>>>>> This code needs a lot of rework, removing duplications, using
>>>>>>>> proper way of materialisation, central response handler and error handler
>>>>>>>> etc. If we clean up this code, some improvements in planner (like using
>>>>>>>> MergeAppend plan) for Sort, will be possible. Regarding materialisation,
>>>>>>>> the code uses a linked list for materialising the rows from datanodes (in
>>>>>>>> case the same connection needs to be given to other remote query node),
>>>>>>>> which must be eating a lot of performance. Instead we should be using some
>>>>>>>> kind of tuplestore there. We actually use tuplestore (as well) in the
>>>>>>>> RemoteQuery node; the same method can be used.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Aug 10, 2013 at 10:48 PM, Nikhil Sontakke <
>>>>>>>> ni...@st...> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Have a Query about ExecRemoteQuery.
>>>>>>>>>
>>>>>>>>> The logic seems to have been modeled after ExecMaterial. ISTM,
>>>>>>>>> that it should have been modeled after ExecScan because we fetch tuples,
>>>>>>>>> and those which match the qual should be sent up. ExecMaterial is for
>>>>>>>>> materializing and collecting and storing tuples.
>>>>>>>>>
>>>>>>>>> Can anyone explain? The reason for asking this is I am suspecting
>>>>>>>>> a big memory leak in this code path. We are not using any expression
>>>>>>>>> context nor we are freeing up tuples as we scan for the one which qualifies.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Nikhils
>>>>>>>>> --
>>>>>>>>> StormDB - http://www.stormdb.com
>>>>>>>>> The Database Cloud
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>>>>>>>> It's a free troubleshooting tool designed for production.
>>>>>>>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>>>>>>>> Download for free and get started troubleshooting in minutes.
>>>>>>>>>
>>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>>>>>>>> _______________________________________________
>>>>>>>>> Postgres-xc-developers mailing list
>>>>>>>>> Pos...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best Wishes,
>>>>>>>> Ashutosh Bapat
>>>>>>>> EntepriseDB Corporation
>>>>>>>> The Postgres Database Company
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best Wishes,
>>>>>>> Ashutosh Bapat
>>>>>>> EntepriseDB Corporation
>>>>>>> The Postgres Database Company
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> StormDB - http://www.stormdb.com
>>>>>> The Database Cloud
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best Wishes,
>>>>> Ashutosh Bapat
>>>>> EntepriseDB Corporation
>>>>> The Postgres Database Company
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> StormDB - http://www.stormdb.com
>>>> The Database Cloud
>>>>
>>>
>>>
>>>
>>> --
>>> Best Wishes,
>>> Ashutosh Bapat
>>> EntepriseDB Corporation
>>> The Postgres Database Company
>>>
>>
>>
>>
>> --
>> StormDB - http://www.stormdb.com
>> The Database Cloud
>>
>
>
>
> --
> StormDB - http://www.stormdb.com
> The Database Cloud
>



-- 
StormDB - http://www.stormdb.com
The Database Cloud

Using a tuplestore for data coming from RemoteQuery is kinda wrong and
that's what has introduced this issue. Looks like just changing the memory
context will not work as it interferes with the other functioning of the
tuplestore :-|

Regards,
Nikhils


On Wed, Aug 14, 2013 at 3:07 PM, Ashutosh Bapat <
ash...@en...> wrote:

> Yes, that's correct.
>
> My patch was not intended to fix this. This was added while fixing a bug
> for parameterised quals on RemoteQuery I think. Check commits by Amit in
> this area.
>
>
> On Wed, Aug 14, 2013 at 3:03 PM, Nikhil Sontakke <ni...@st...>wrote:
>
>> Yeah, but AFAICS, even 1.1 (and head) *still* has a leak in it.
>>
>> Here's the snippet from RemoteQueryNext:
>>
>> if (tuplestorestate && !TupIsNull(scanslot))
>>                     tuplestore_puttupleslot(tuplestorestate, scanslot);
>>
>> I printed the current memory context inside this function, it is
>> ""ExecutorState". This means that the tuple will stay around till the query
>> is executing in its entirety! For large COPY queries this is bound to cause
>> issues as is also reported by Hitoshi san on another thread.
>>
>> I propose that in RemoteQueryNext, before calling the
>> tuplestore_puttupleslot we switch into
>> scan_node->ps.ps_ExprContext's ecxt_per_tuple_memory context. It will get
>> reset, when the next tuple has to be returned to the caller and the leak
>> will be curtailed. Thoughts?
>>
>> Regards,
>> Nikhils
>>
>>
>>
>>
>> On Wed, Aug 14, 2013 at 11:33 AM, Ashutosh Bapat <
>> ash...@en...> wrote:
>>
>>> There has been an overhaul in the planner (and corresponding parts of
>>> executor) in 1.1, so it would be better if they move to 1.1 after GA.
>>>
>>>
>>> On Wed, Aug 14, 2013 at 10:54 AM, Nikhil Sontakke <ni...@st...>wrote:
>>>
>>>> Ah, I see.
>>>>
>>>> I was looking at REL_1_0 sources.
>>>>
>>>> There are people out there using REL_1_0 as well.
>>>>
>>>> Regards,
>>>> Nikhils
>>>>
>>>>
>>>> On Tue, Aug 13, 2013 at 9:52 AM, Ashutosh Bapat <
>>>> ash...@en...> wrote:
>>>>
>>>>> It should be part of 1.1 as well. It was done to support projection
>>>>> out of RemoteQuery node.
>>>>>
>>>>>
>>>>> On Tue, Aug 13, 2013 at 7:17 AM, Nikhil Sontakke <ni...@st...>wrote:
>>>>>
>>>>>> Hi Ashutosh,
>>>>>>
>>>>>> I guess you have changed it in pgxc head? I was looking at 103 and 11
>>>>>> branches and saw this. In that even ExecRemoteQuery seems to have an issue
>>>>>> wherein it's not using the appropriate context.
>>>>>>
>>>>>> Regards,
>>>>>> Nikhils
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Aug 12, 2013, at 9:54 AM, Ashutosh Bapat <
>>>>>> ash...@en...> wrote:
>>>>>>
>>>>>>
>>>>>> Welcome to the mess ;) and enjoy junk food.
>>>>>>
>>>>>> Sometime back, I have changed ExecRemoteQuery to be called in the
>>>>>> same fashion as other Scan nodes. So, you will see ExecRemoteQuery calling
>>>>>> ExecScan with RemoteQueryNext as the iterator. So, I assume your comment
>>>>>> pertains to RemoteQueryNext and its minions and not ExecRemoteQuery per say!
>>>>>>
>>>>>> This code needs a lot of rework, removing duplications, using proper
>>>>>> way of materialisation, central response handler and error handler etc. If
>>>>>> we clean up this code, some improvements in planner (like using MergeAppend
>>>>>> plan) for Sort, will be possible. Regarding materialisation, the code uses
>>>>>> a linked list for materialising the rows from datanodes (in case the same
>>>>>> connection needs to be given to other remote query node), which must be
>>>>>> eating a lot of performance. Instead we should be using some kind of
>>>>>> tuplestore there. We actually use tuplestore (as well) in the RemoteQuery
>>>>>> node; the same method can be used.
>>>>>>
>>>>>>
>>>>>> On Sat, Aug 10, 2013 at 10:48 PM, Nikhil Sontakke <
>>>>>> ni...@st...> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Have a Query about ExecRemoteQuery.
>>>>>>>
>>>>>>> The logic seems to have been modeled after ExecMaterial. ISTM, that
>>>>>>> it should have been modeled after ExecScan because we fetch tuples, and
>>>>>>> those which match the qual should be sent up. ExecMaterial is for
>>>>>>> materializing and collecting and storing tuples.
>>>>>>>
>>>>>>> Can anyone explain? The reason for asking this is I am suspecting a
>>>>>>> big memory leak in this code path. We are not using any expression context
>>>>>>> nor we are freeing up tuples as we scan for the one which qualifies.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Nikhils
>>>>>>> --
>>>>>>> StormDB - http://www.stormdb.com
>>>>>>> The Database Cloud
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>>>>>> It's a free troubleshooting tool designed for production.
>>>>>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>>>>>> Download for free and get started troubleshooting in minutes.
>>>>>>>
>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>>>>>> _______________________________________________
>>>>>>> Postgres-xc-developers mailing list
>>>>>>> Pos...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best Wishes,
>>>>>> Ashutosh Bapat
>>>>>> EntepriseDB Corporation
>>>>>> The Postgres Database Company
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best Wishes,
>>>>> Ashutosh Bapat
>>>>> EntepriseDB Corporation
>>>>> The Postgres Database Company
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> StormDB - http://www.stormdb.com
>>>> The Database Cloud
>>>>
>>>
>>>
>>>
>>> --
>>> Best Wishes,
>>> Ashutosh Bapat
>>> EntepriseDB Corporation
>>> The Postgres Database Company
>>>
>>
>>
>>
>> --
>> StormDB - http://www.stormdb.com
>> The Database Cloud
>>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Postgres Database Company
>



-- 
StormDB - http://www.stormdb.com
The Database Cloud

Hi Ashtosh,

Thanks for your comment!

 > The code changes are fine, but, the comment in pgxc_collect_RTE_walker()
 > seems to specific. I think it should read, "create a copy of query's 
range
 > table, so that it can be linked with other RTEs in the collector's 
context."
 >
I've revised the comment as you suggested.

 > In the test file, isn't there any way, you can add the offending statent
 > without any wrapper function test_execute_direct_all_xc_nodes()? We 
should
 > minimize the test-code to use only the minimal set of features. Since 
this
 > statement no more gets into infinite loop, please do not use the 
statement
 > timeout.

I've gotten rid of using statement timeout.
But I couldn't come up any idea to testing more simply,
so the function is remaining as same as before patch.
Any ideas?

Here is the new patch.
(against dec40008b3d689911566514614c5111c0a61327d)

regards,
-------------
NTT Software Corporation
Tomonari Katsumata

Yes, that's correct.

My patch was not intended to fix this. This was added while fixing a bug
for parameterised quals on RemoteQuery I think. Check commits by Amit in
this area.


On Wed, Aug 14, 2013 at 3:03 PM, Nikhil Sontakke <ni...@st...>wrote:

> Yeah, but AFAICS, even 1.1 (and head) *still* has a leak in it.
>
> Here's the snippet from RemoteQueryNext:
>
> if (tuplestorestate && !TupIsNull(scanslot))
>                     tuplestore_puttupleslot(tuplestorestate, scanslot);
>
> I printed the current memory context inside this function, it is
> ""ExecutorState". This means that the tuple will stay around till the query
> is executing in its entirety! For large COPY queries this is bound to cause
> issues as is also reported by Hitoshi san on another thread.
>
> I propose that in RemoteQueryNext, before calling the
> tuplestore_puttupleslot we switch into
> scan_node->ps.ps_ExprContext's ecxt_per_tuple_memory context. It will get
> reset, when the next tuple has to be returned to the caller and the leak
> will be curtailed. Thoughts?
>
> Regards,
> Nikhils
>
>
>
>
> On Wed, Aug 14, 2013 at 11:33 AM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>> There has been an overhaul in the planner (and corresponding parts of
>> executor) in 1.1, so it would be better if they move to 1.1 after GA.
>>
>>
>> On Wed, Aug 14, 2013 at 10:54 AM, Nikhil Sontakke <ni...@st...>wrote:
>>
>>> Ah, I see.
>>>
>>> I was looking at REL_1_0 sources.
>>>
>>> There are people out there using REL_1_0 as well.
>>>
>>> Regards,
>>> Nikhils
>>>
>>>
>>> On Tue, Aug 13, 2013 at 9:52 AM, Ashutosh Bapat <
>>> ash...@en...> wrote:
>>>
>>>> It should be part of 1.1 as well. It was done to support projection out
>>>> of RemoteQuery node.
>>>>
>>>>
>>>> On Tue, Aug 13, 2013 at 7:17 AM, Nikhil Sontakke <ni...@st...>wrote:
>>>>
>>>>> Hi Ashutosh,
>>>>>
>>>>> I guess you have changed it in pgxc head? I was looking at 103 and 11
>>>>> branches and saw this. In that even ExecRemoteQuery seems to have an issue
>>>>> wherein it's not using the appropriate context.
>>>>>
>>>>> Regards,
>>>>> Nikhils
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Aug 12, 2013, at 9:54 AM, Ashutosh Bapat <
>>>>> ash...@en...> wrote:
>>>>>
>>>>>
>>>>> Welcome to the mess ;) and enjoy junk food.
>>>>>
>>>>> Sometime back, I have changed ExecRemoteQuery to be called in the same
>>>>> fashion as other Scan nodes. So, you will see ExecRemoteQuery calling
>>>>> ExecScan with RemoteQueryNext as the iterator. So, I assume your comment
>>>>> pertains to RemoteQueryNext and its minions and not ExecRemoteQuery per say!
>>>>>
>>>>> This code needs a lot of rework, removing duplications, using proper
>>>>> way of materialisation, central response handler and error handler etc. If
>>>>> we clean up this code, some improvements in planner (like using MergeAppend
>>>>> plan) for Sort, will be possible. Regarding materialisation, the code uses
>>>>> a linked list for materialising the rows from datanodes (in case the same
>>>>> connection needs to be given to other remote query node), which must be
>>>>> eating a lot of performance. Instead we should be using some kind of
>>>>> tuplestore there. We actually use tuplestore (as well) in the RemoteQuery
>>>>> node; the same method can be used.
>>>>>
>>>>>
>>>>> On Sat, Aug 10, 2013 at 10:48 PM, Nikhil Sontakke <ni...@st...
>>>>> > wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Have a Query about ExecRemoteQuery.
>>>>>>
>>>>>> The logic seems to have been modeled after ExecMaterial. ISTM, that
>>>>>> it should have been modeled after ExecScan because we fetch tuples, and
>>>>>> those which match the qual should be sent up. ExecMaterial is for
>>>>>> materializing and collecting and storing tuples.
>>>>>>
>>>>>> Can anyone explain? The reason for asking this is I am suspecting a
>>>>>> big memory leak in this code path. We are not using any expression context
>>>>>> nor we are freeing up tuples as we scan for the one which qualifies.
>>>>>>
>>>>>> Regards,
>>>>>> Nikhils
>>>>>> --
>>>>>> StormDB - http://www.stormdb.com
>>>>>> The Database Cloud
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>>>>> It's a free troubleshooting tool designed for production.
>>>>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>>>>> Download for free and get started troubleshooting in minutes.
>>>>>>
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>>>>> _______________________________________________
>>>>>> Postgres-xc-developers mailing list
>>>>>> Pos...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best Wishes,
>>>>> Ashutosh Bapat
>>>>> EntepriseDB Corporation
>>>>> The Postgres Database Company
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best Wishes,
>>>> Ashutosh Bapat
>>>> EntepriseDB Corporation
>>>> The Postgres Database Company
>>>>
>>>
>>>
>>>
>>> --
>>> StormDB - http://www.stormdb.com
>>> The Database Cloud
>>>
>>
>>
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>> EntepriseDB Corporation
>> The Postgres Database Company
>>
>
>
>
> --
> StormDB - http://www.stormdb.com
> The Database Cloud
>



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

Yeah, but AFAICS, even 1.1 (and head) *still* has a leak in it.

Here's the snippet from RemoteQueryNext:

if (tuplestorestate && !TupIsNull(scanslot))
                    tuplestore_puttupleslot(tuplestorestate, scanslot);

I printed the current memory context inside this function, it is
""ExecutorState". This means that the tuple will stay around till the query
is executing in its entirety! For large COPY queries this is bound to cause
issues as is also reported by Hitoshi san on another thread.

I propose that in RemoteQueryNext, before calling the
tuplestore_puttupleslot we switch into
scan_node->ps.ps_ExprContext's ecxt_per_tuple_memory context. It will get
reset, when the next tuple has to be returned to the caller and the leak
will be curtailed. Thoughts?

Regards,
Nikhils



On Wed, Aug 14, 2013 at 11:33 AM, Ashutosh Bapat <
ash...@en...> wrote:

> There has been an overhaul in the planner (and corresponding parts of
> executor) in 1.1, so it would be better if they move to 1.1 after GA.
>
>
> On Wed, Aug 14, 2013 at 10:54 AM, Nikhil Sontakke <ni...@st...>wrote:
>
>> Ah, I see.
>>
>> I was looking at REL_1_0 sources.
>>
>> There are people out there using REL_1_0 as well.
>>
>> Regards,
>> Nikhils
>>
>>
>> On Tue, Aug 13, 2013 at 9:52 AM, Ashutosh Bapat <
>> ash...@en...> wrote:
>>
>>> It should be part of 1.1 as well. It was done to support projection out
>>> of RemoteQuery node.
>>>
>>>
>>> On Tue, Aug 13, 2013 at 7:17 AM, Nikhil Sontakke <ni...@st...>wrote:
>>>
>>>> Hi Ashutosh,
>>>>
>>>> I guess you have changed it in pgxc head? I was looking at 103 and 11
>>>> branches and saw this. In that even ExecRemoteQuery seems to have an issue
>>>> wherein it's not using the appropriate context.
>>>>
>>>> Regards,
>>>> Nikhils
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Aug 12, 2013, at 9:54 AM, Ashutosh Bapat <
>>>> ash...@en...> wrote:
>>>>
>>>>
>>>> Welcome to the mess ;) and enjoy junk food.
>>>>
>>>> Sometime back, I have changed ExecRemoteQuery to be called in the same
>>>> fashion as other Scan nodes. So, you will see ExecRemoteQuery calling
>>>> ExecScan with RemoteQueryNext as the iterator. So, I assume your comment
>>>> pertains to RemoteQueryNext and its minions and not ExecRemoteQuery per say!
>>>>
>>>> This code needs a lot of rework, removing duplications, using proper
>>>> way of materialisation, central response handler and error handler etc. If
>>>> we clean up this code, some improvements in planner (like using MergeAppend
>>>> plan) for Sort, will be possible. Regarding materialisation, the code uses
>>>> a linked list for materialising the rows from datanodes (in case the same
>>>> connection needs to be given to other remote query node), which must be
>>>> eating a lot of performance. Instead we should be using some kind of
>>>> tuplestore there. We actually use tuplestore (as well) in the RemoteQuery
>>>> node; the same method can be used.
>>>>
>>>>
>>>> On Sat, Aug 10, 2013 at 10:48 PM, Nikhil Sontakke <ni...@st...>wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Have a Query about ExecRemoteQuery.
>>>>>
>>>>> The logic seems to have been modeled after ExecMaterial. ISTM, that it
>>>>> should have been modeled after ExecScan because we fetch tuples, and those
>>>>> which match the qual should be sent up. ExecMaterial is for materializing
>>>>> and collecting and storing tuples.
>>>>>
>>>>> Can anyone explain? The reason for asking this is I am suspecting a
>>>>> big memory leak in this code path. We are not using any expression context
>>>>> nor we are freeing up tuples as we scan for the one which qualifies.
>>>>>
>>>>> Regards,
>>>>> Nikhils
>>>>> --
>>>>> StormDB - http://www.stormdb.com
>>>>> The Database Cloud
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>>>> It's a free troubleshooting tool designed for production.
>>>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>>>> Download for free and get started troubleshooting in minutes.
>>>>>
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Postgres-xc-developers mailing list
>>>>> Pos...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best Wishes,
>>>> Ashutosh Bapat
>>>> EntepriseDB Corporation
>>>> The Postgres Database Company
>>>>
>>>>
>>>
>>>
>>> --
>>> Best Wishes,
>>> Ashutosh Bapat
>>> EntepriseDB Corporation
>>> The Postgres Database Company
>>>
>>
>>
>>
>> --
>> StormDB - http://www.stormdb.com
>> The Database Cloud
>>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Postgres Database Company
>



-- 
StormDB - http://www.stormdb.com
The Database Cloud

There has been an overhaul in the planner (and corresponding parts of
executor) in 1.1, so it would be better if they move to 1.1 after GA.


On Wed, Aug 14, 2013 at 10:54 AM, Nikhil Sontakke <ni...@st...>wrote:

> Ah, I see.
>
> I was looking at REL_1_0 sources.
>
> There are people out there using REL_1_0 as well.
>
> Regards,
> Nikhils
>
>
> On Tue, Aug 13, 2013 at 9:52 AM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>> It should be part of 1.1 as well. It was done to support projection out
>> of RemoteQuery node.
>>
>>
>> On Tue, Aug 13, 2013 at 7:17 AM, Nikhil Sontakke <ni...@st...>wrote:
>>
>>> Hi Ashutosh,
>>>
>>> I guess you have changed it in pgxc head? I was looking at 103 and 11
>>> branches and saw this. In that even ExecRemoteQuery seems to have an issue
>>> wherein it's not using the appropriate context.
>>>
>>> Regards,
>>> Nikhils
>>>
>>> Sent from my iPhone
>>>
>>> On Aug 12, 2013, at 9:54 AM, Ashutosh Bapat <
>>> ash...@en...> wrote:
>>>
>>>
>>> Welcome to the mess ;) and enjoy junk food.
>>>
>>> Sometime back, I have changed ExecRemoteQuery to be called in the same
>>> fashion as other Scan nodes. So, you will see ExecRemoteQuery calling
>>> ExecScan with RemoteQueryNext as the iterator. So, I assume your comment
>>> pertains to RemoteQueryNext and its minions and not ExecRemoteQuery per say!
>>>
>>> This code needs a lot of rework, removing duplications, using proper way
>>> of materialisation, central response handler and error handler etc. If we
>>> clean up this code, some improvements in planner (like using MergeAppend
>>> plan) for Sort, will be possible. Regarding materialisation, the code uses
>>> a linked list for materialising the rows from datanodes (in case the same
>>> connection needs to be given to other remote query node), which must be
>>> eating a lot of performance. Instead we should be using some kind of
>>> tuplestore there. We actually use tuplestore (as well) in the RemoteQuery
>>> node; the same method can be used.
>>>
>>>
>>> On Sat, Aug 10, 2013 at 10:48 PM, Nikhil Sontakke <ni...@st...>wrote:
>>>
>>>> Hi,
>>>>
>>>> Have a Query about ExecRemoteQuery.
>>>>
>>>> The logic seems to have been modeled after ExecMaterial. ISTM, that it
>>>> should have been modeled after ExecScan because we fetch tuples, and those
>>>> which match the qual should be sent up. ExecMaterial is for materializing
>>>> and collecting and storing tuples.
>>>>
>>>> Can anyone explain? The reason for asking this is I am suspecting a big
>>>> memory leak in this code path. We are not using any expression context nor
>>>> we are freeing up tuples as we scan for the one which qualifies.
>>>>
>>>> Regards,
>>>> Nikhils
>>>> --
>>>> StormDB - http://www.stormdb.com
>>>> The Database Cloud
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>>> It's a free troubleshooting tool designed for production.
>>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>>> Download for free and get started troubleshooting in minutes.
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Postgres-xc-developers mailing list
>>>> Pos...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>
>>>>
>>>
>>>
>>> --
>>> Best Wishes,
>>> Ashutosh Bapat
>>> EntepriseDB Corporation
>>> The Postgres Database Company
>>>
>>>
>>
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>> EntepriseDB Corporation
>> The Postgres Database Company
>>
>
>
>
> --
> StormDB - http://www.stormdb.com
> The Database Cloud
>



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

Ah, I see.

I was looking at REL_1_0 sources.

There are people out there using REL_1_0 as well.

Regards,
Nikhils

On Tue, Aug 13, 2013 at 9:52 AM, Ashutosh Bapat <
ash...@en...> wrote:

> It should be part of 1.1 as well. It was done to support projection out of
> RemoteQuery node.
>
>
> On Tue, Aug 13, 2013 at 7:17 AM, Nikhil Sontakke <ni...@st...>wrote:
>
>> Hi Ashutosh,
>>
>> I guess you have changed it in pgxc head? I was looking at 103 and 11
>> branches and saw this. In that even ExecRemoteQuery seems to have an issue
>> wherein it's not using the appropriate context.
>>
>> Regards,
>> Nikhils
>>
>> Sent from my iPhone
>>
>> On Aug 12, 2013, at 9:54 AM, Ashutosh Bapat <
>> ash...@en...> wrote:
>>
>>
>> Welcome to the mess ;) and enjoy junk food.
>>
>> Sometime back, I have changed ExecRemoteQuery to be called in the same
>> fashion as other Scan nodes. So, you will see ExecRemoteQuery calling
>> ExecScan with RemoteQueryNext as the iterator. So, I assume your comment
>> pertains to RemoteQueryNext and its minions and not ExecRemoteQuery per say!
>>
>> This code needs a lot of rework, removing duplications, using proper way
>> of materialisation, central response handler and error handler etc. If we
>> clean up this code, some improvements in planner (like using MergeAppend
>> plan) for Sort, will be possible. Regarding materialisation, the code uses
>> a linked list for materialising the rows from datanodes (in case the same
>> connection needs to be given to other remote query node), which must be
>> eating a lot of performance. Instead we should be using some kind of
>> tuplestore there. We actually use tuplestore (as well) in the RemoteQuery
>> node; the same method can be used.
>>
>>
>> On Sat, Aug 10, 2013 at 10:48 PM, Nikhil Sontakke <ni...@st...>wrote:
>>
>>> Hi,
>>>
>>> Have a Query about ExecRemoteQuery.
>>>
>>> The logic seems to have been modeled after ExecMaterial. ISTM, that it
>>> should have been modeled after ExecScan because we fetch tuples, and those
>>> which match the qual should be sent up. ExecMaterial is for materializing
>>> and collecting and storing tuples.
>>>
>>> Can anyone explain? The reason for asking this is I am suspecting a big
>>> memory leak in this code path. We are not using any expression context nor
>>> we are freeing up tuples as we scan for the one which qualifies.
>>>
>>> Regards,
>>> Nikhils
>>> --
>>> StormDB - http://www.stormdb.com
>>> The Database Cloud
>>>
>>> ------------------------------------------------------------------------------
>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>> It's a free troubleshooting tool designed for production.
>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>> Download for free and get started troubleshooting in minutes.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Postgres-xc-developers mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>
>>>
>>
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>> EntepriseDB Corporation
>> The Postgres Database Company
>>
>>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Postgres Database Company
>



-- 
StormDB - http://www.stormdb.com
The Database Cloud

Right, that's one thing, other thing is we don't want to initiate two
queries simultaneously on the same node. In a plan tree with multiple
RemoteQuery nodes, this is very much possible.


On Wed, Aug 14, 2013 at 9:46 AM, Pavan Deolasee <pav...@gm...>wrote:

> On Wed, Aug 7, 2013 at 2:12 PM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>>
>>>
>> This can be done if we move "issueing query" inside ExecInitRemoteQuery,
>> but I am not sure if that can be applied in all the cases. This wouldn't
>> require any change in PG.
>>
>>
>
> I am not sure either. AFAICS we only do initialization in that path. For
> example, Explain will also call ExecutorStart (which in turns initializes
> all the nodes). And we definitely don't want to run a query when its being
> explained.
>
>
> Thanks,
> Pavan
>
> --
> Pavan Deolasee
> http://www.linkedin.com/in/pavandeolasee
>



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

On Wed, Aug 7, 2013 at 2:12 PM, Ashutosh Bapat <
ash...@en...> wrote:

>
>>
> This can be done if we move "issueing query" inside ExecInitRemoteQuery,
> but I am not sure if that can be applied in all the cases. This wouldn't
> require any change in PG.
>
>

I am not sure either. AFAICS we only do initialization in that path. For
example, Explain will also call ExecutorStart (which in turns initializes
all the nodes). And we definitely don't want to run a query when its being
explained.

Thanks,
Pavan

-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

Hi Tomonari,
The code changes are fine, but, the comment in pgxc_collect_RTE_walker()
seems to specific. I think it should read, "create a copy of query's range
table, so that it can be linked with other RTEs in the collector's context."

In the test file, isn't there any way, you can add the offending statent
without any wrapper function test_execute_direct_all_xc_nodes()? We should
minimize the test-code to use only the minimal set of features. Since this
statement no more gets into infinite loop, please do not use the statement
timeout.


On Sat, Aug 10, 2013 at 11:21 AM, Tomonari Katsumata <
t.k...@gm...> wrote:

> Hi,
>
> Sorry for begin for long waiting...
>
> I've revised my patch.
> The patch is revised_fqs_r2.patch.
> This is a patch for (e684b405779d0d348309d011249e4f5439f8d304)
>
>
> 2013/7/22 Tomonari Katsumata <kat...@po...>
>
>> Hi Abbas,
>>
>> (2013/07/19 20:37), Abbas Butt wrote:
>>
>
>
>>   > 1. The problem you reported seems to be caused by a missing
>> initialization
>>  > i.e.
>>  > query->rtable = NIL;
>>  > Can you please explain why did the server crash and how it got fixed by
>>  > having the above initialization statement?
>> The fix has nothing to do with server crash.
>> The test environment(2datanodes and 1cordinator) avoids the crash.
>>
>>  > It would be nice to add some comment on top of this line explaining it.
>>  >
>> To be honest, I don't know why my fix solves
>> my infinite loop problem.
>> I'll check it deeper and revise the patch.
>> Please wait for it.
>>
>
> It seems that my old fix is not good.
> Because all rtable data is ignored.
> So I changed the place to fix to pgxc_collect_RTE_walker in pgxcplan.c.
> When concating lists, I make a copy of a list.
> This was suggested by Ashtosh before, and I've confirm
> I can avoid my problem with this.
>
>
>>
>>  > 2. I think your patch unintentionally includes a change in
>>  > contrib/pgxc_ctl/signature.h
>>  >     Can you please remove it?
>>  >
>> OK, I'll do it.
>>
>
> done.
>
>
>>
>>  > 3. Can you please add a test case in say xc_misc.sql?
>>  >
>> OK, I'll do it too.
>>
>
> done.
>
> regards,
> -------------
> NTT Software Corporation
> Tomonari Katsumata
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


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

Hi *,

if I make a connection to a gtm_proxy (telnet, netcat), send some bytes (or not) and close the connection (or not), the proxy seems to be dead afterwards.

"monitor all" from pgxc_ctl hangs forever when checking the gtm proxy. It (the proxy) still accepts connections, but does no datahandling (according to strace).

The only way to re-animate such a proxy is to kill and restart it.


I know I can protect my proxies with a firewall, but I guess that any broken connections could result in DOS, too. (I tried to connect via nc in order to see, if the service is alive. All other services are fine with theese kind of connections).

Unfortunatly I was not able to track this error down in the sourcecode. If you need more information, please let me know.

Greetings,
Stefan

It should be part of 1.1 as well. It was done to support projection out of
RemoteQuery node.


On Tue, Aug 13, 2013 at 7:17 AM, Nikhil Sontakke <ni...@st...>wrote:

> Hi Ashutosh,
>
> I guess you have changed it in pgxc head? I was looking at 103 and 11
> branches and saw this. In that even ExecRemoteQuery seems to have an issue
> wherein it's not using the appropriate context.
>
> Regards,
> Nikhils
>
> Sent from my iPhone
>
> On Aug 12, 2013, at 9:54 AM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>
> Welcome to the mess ;) and enjoy junk food.
>
> Sometime back, I have changed ExecRemoteQuery to be called in the same
> fashion as other Scan nodes. So, you will see ExecRemoteQuery calling
> ExecScan with RemoteQueryNext as the iterator. So, I assume your comment
> pertains to RemoteQueryNext and its minions and not ExecRemoteQuery per say!
>
> This code needs a lot of rework, removing duplications, using proper way
> of materialisation, central response handler and error handler etc. If we
> clean up this code, some improvements in planner (like using MergeAppend
> plan) for Sort, will be possible. Regarding materialisation, the code uses
> a linked list for materialising the rows from datanodes (in case the same
> connection needs to be given to other remote query node), which must be
> eating a lot of performance. Instead we should be using some kind of
> tuplestore there. We actually use tuplestore (as well) in the RemoteQuery
> node; the same method can be used.
>
>
> On Sat, Aug 10, 2013 at 10:48 PM, Nikhil Sontakke <ni...@st...>wrote:
>
>> Hi,
>>
>> Have a Query about ExecRemoteQuery.
>>
>> The logic seems to have been modeled after ExecMaterial. ISTM, that it
>> should have been modeled after ExecScan because we fetch tuples, and those
>> which match the qual should be sent up. ExecMaterial is for materializing
>> and collecting and storing tuples.
>>
>> Can anyone explain? The reason for asking this is I am suspecting a big
>> memory leak in this code path. We are not using any expression context nor
>> we are freeing up tuples as we scan for the one which qualifies.
>>
>> Regards,
>> Nikhils
>> --
>> StormDB - http://www.stormdb.com
>> The Database Cloud
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>
>>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Postgres Database Company
>
>


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

Hi Ashutosh,

I guess you have changed it in pgxc head? I was looking at 103 and 11
branches and saw this. In that even ExecRemoteQuery seems to have an issue
wherein it's not using the appropriate context.

Regards,
Nikhils

Sent from my iPhone

On Aug 12, 2013, at 9:54 AM, Ashutosh Bapat <ash...@en...>
wrote:


Welcome to the mess ;) and enjoy junk food.

Sometime back, I have changed ExecRemoteQuery to be called in the same
fashion as other Scan nodes. So, you will see ExecRemoteQuery calling
ExecScan with RemoteQueryNext as the iterator. So, I assume your comment
pertains to RemoteQueryNext and its minions and not ExecRemoteQuery per say!

This code needs a lot of rework, removing duplications, using proper way of
materialisation, central response handler and error handler etc. If we
clean up this code, some improvements in planner (like using MergeAppend
plan) for Sort, will be possible. Regarding materialisation, the code uses
a linked list for materialising the rows from datanodes (in case the same
connection needs to be given to other remote query node), which must be
eating a lot of performance. Instead we should be using some kind of
tuplestore there. We actually use tuplestore (as well) in the RemoteQuery
node; the same method can be used.


On Sat, Aug 10, 2013 at 10:48 PM, Nikhil Sontakke <ni...@st...>wrote:

> Hi,
>
> Have a Query about ExecRemoteQuery.
>
> The logic seems to have been modeled after ExecMaterial. ISTM, that it
> should have been modeled after ExecScan because we fetch tuples, and those
> which match the qual should be sent up. ExecMaterial is for materializing
> and collecting and storing tuples.
>
> Can anyone explain? The reason for asking this is I am suspecting a big
> memory leak in this code path. We are not using any expression context nor
> we are freeing up tuples as we scan for the one which qualifies.
>
> Regards,
> Nikhils
> --
> StormDB - http://www.stormdb.com
> The Database Cloud
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


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

On Mon, Aug 12, 2013 at 6:16 PM, Pavan Deolasee
<pav...@gm...> wrote:
> If we at all want to rework that, IMHO we should just use ForeignScan with
> appropriate enhancements to the node and/or addition of a new node to
> effectively combine results from multiple ForeignScan nodes.
Completely agreed with that for SELECT queries with FQS planner and
clause pushdowns plugged on top of it. This would make XC more closely
implemented with vanilla PG.
-- 
Michael

Since Bison 3.0 they stopped support for YYPARSE_PARAM, which is used in
contrib/cube and contrib/seg. More can be read at:
http://www.postgresql.org/message-id/736...@ss...

There is a patch for PostgreSQL which fixes this but doesn't apply clean on
Postgres-XC 1.0.3 without some minor changes.

Attached is the patch for 1.0.3. Tested with bison 3.0 and 2.7.1. Both compile
without errors.

--
Regards,
Jure Kobal

Hi,

I found a odd behavior with gtm_standby(gtm_sby).
When the network to gtm_master is broken, gtm_ctl couldn't stop gtm_sby
even if I add an option "-m i".

I simulates the situation with iptables command.
(gtm_sby access to gtm_master via eth1)
# iptables -I INPUT -i eth1 -j DROP
# iptables -I OUTPUT -o eth1 -j DROP

And then, I start and stop immediately with these commands.
$ gtm_ctl -D <gtm_sby-PATH> -Z gtm start
$ gtm_ctl -D <gtm_sby-PATH> -Z gtm stop -m i

The last command left below message.
-------
waiting for server to shut
down............................................................... failed
gtm_ctl: server does not shut down
--------

But actually gtm_sby has stoped while the last command.

In my opinion, stopping with "-m i" should stop gtm_sby immediately.
Because vanilla-PostgreSQL do so.

Should we resolve this problem?

regards,
--------
NTT Software Corporation
Tomonari Katsumata

Hi Guys,

I have a problem. While upgrading to latest sources last week, my testbed stopped working. I get the error message:

FATAL:  3D000: database "postgres-xc" does not exist

I get this message on all datanodes and all coordinators. GMT Log shows no errors.


I have no idea where this problem comes from and would be greatful for any hints!


Attached you find the pgxc_ctl.conf, the logfile from the init all run and the output of show configuration all

I included the full Logfile from the datanode-master (node dbms181 on server dbms181) in this message.



Greetings,
Stefan


Full Logfile from Datanode-Master:
LOG:  00000: database system was shut down at 2013-08-12 13:25:44 UTC
LOCATION:  StartupXLOG, xlog.c:6344
LOG:  00000: database system is ready to accept connections
LOCATION:  reaper, postmaster.c:2560
LOG:  00000: autovacuum launcher started
LOCATION:  AutoVacLauncherMain, autovacuum.c:407
LOG:  00000: connection received: host=gtm81 port=60914
LOCATION:  BackendInitialize, postmaster.c:3666
LOG:  00000: connection authorized: user=postgres-xc database=postgres-xc
LOCATION:  PerformAuthentication, postinit.c:229
FATAL:  3D000: database "postgres-xc" does not exist
LOCATION:  InitPostgres, postinit.c:716
LOG:  00000: connection received: host=dbms297 port=38572
LOCATION:  BackendInitialize, postmaster.c:3666
LOG:  00000: replication connection authorized: user=postgres-xc
LOCATION:  PerformAuthentication, postinit.c:225
LOG:  00000: checkpoint starting: force wait
LOCATION:  LogCheckpointStart, xlog.c:7902
LOG:  00000: checkpoint complete: wrote 0 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=0.000 s, sync=0.000 s, total=0.365 s; sync files=0, longest=0.000 s, average=0.000 s
LOCATION:  LogCheckpointEnd, xlog.c:7990
Warning: Permanently added 'dbms297,10.182.201.109' (ECDSA) to the list of known hosts.
Warning: Permanently added 'dbms297,10.182.201.109' (ECDSA) to the list of known hosts.
LOG:  00000: disconnection: session time: 0:00:04.583 user=postgres-xc database= host=dbms297 port=38572
LOCATION:  log_disconnections, postgres.c:4707
Warning: Permanently added 'dbms297,10.182.201.109' (ECDSA) to the list of known hosts.
LOG:  00000: connection received: host=gtm81 port=60950
LOCATION:  BackendInitialize, postmaster.c:3666
LOG:  00000: connection authorized: user=postgres-xc database=postgres-xc
LOCATION:  PerformAuthentication, postinit.c:229
FATAL:  3D000: database "postgres-xc" does not exist
LOCATION:  InitPostgres, postinit.c:716
LOG:  00000: connection received: host=dbms297 port=38573
LOCATION:  BackendInitialize, postmaster.c:3666
LOG:  00000: replication connection authorized: user=postgres-xc
LOCATION:  PerformAuthentication, postinit.c:225
LOG:  00000: connection received: host=gtm81 port=60983
LOCATION:  BackendInitialize, postmaster.c:3666
LOG:  00000: connection authorized: user=postgres-xc database=postgres-xc
LOCATION:  PerformAuthentication, postinit.c:229
FATAL:  3D000: database "postgres-xc" does not exist
LOCATION:  InitPostgres, postinit.c:716

On Mon, Aug 12, 2013 at 9:54 AM, Ashutosh Bapat <
ash...@en...> wrote:

>
> Welcome to the mess ;) and enjoy junk food.
>
> Sometime back, I have changed ExecRemoteQuery to be called in the same
> fashion as other Scan nodes. So, you will see ExecRemoteQuery calling
> ExecScan with RemoteQueryNext as the iterator. So, I assume your comment
> pertains to RemoteQueryNext and its minions and not ExecRemoteQuery per say!
>
> This code needs a lot of rework, removing duplications, using proper way
> of materialisation, central response handler and error handler etc. If we
> clean up this code, some improvements in planner (like using MergeAppend
> plan) for Sort, will be possible. Regarding materialisation, the code uses
> a linked list for materialising the rows from datanodes (in case the same
> connection needs to be given to other remote query node), which must be
> eating a lot of performance. Instead we should be using some kind of
> tuplestore there. We actually use tuplestore (as well) in the RemoteQuery
> node; the same method can be used.
>
>
If we at all want to rework that, IMHO we should just use ForeignScan with
appropriate enhancements to the node and/or addition of a new node to
effectively combine results from multiple ForeignScan nodes.

Thanks,
Pavan

-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

Welcome to the mess ;) and enjoy junk food.

Sometime back, I have changed ExecRemoteQuery to be called in the same
fashion as other Scan nodes. So, you will see ExecRemoteQuery calling
ExecScan with RemoteQueryNext as the iterator. So, I assume your comment
pertains to RemoteQueryNext and its minions and not ExecRemoteQuery per say!

This code needs a lot of rework, removing duplications, using proper way of
materialisation, central response handler and error handler etc. If we
clean up this code, some improvements in planner (like using MergeAppend
plan) for Sort, will be possible. Regarding materialisation, the code uses
a linked list for materialising the rows from datanodes (in case the same
connection needs to be given to other remote query node), which must be
eating a lot of performance. Instead we should be using some kind of
tuplestore there. We actually use tuplestore (as well) in the RemoteQuery
node; the same method can be used.


On Sat, Aug 10, 2013 at 10:48 PM, Nikhil Sontakke <ni...@st...>wrote:

> Hi,
>
> Have a Query about ExecRemoteQuery.
>
> The logic seems to have been modeled after ExecMaterial. ISTM, that it
> should have been modeled after ExecScan because we fetch tuples, and those
> which match the qual should be sent up. ExecMaterial is for materializing
> and collecting and storing tuples.
>
> Can anyone explain? The reason for asking this is I am suspecting a big
> memory leak in this code path. We are not using any expression context nor
> we are freeing up tuples as we scan for the one which qualifies.
>
> Regards,
> Nikhils
> --
> StormDB - http://www.stormdb.com
> The Database Cloud
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


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

Andrei;

Thank you very much for the report and the fix.   I committed both patches
for all the versions.

It's even better if you provide a test script to create more than 1024
sequence.

Best Regards;
---
Koichi Suzuki


2013/8/8 Andrei Martsinchyk <and...@gm...>

> Hi,
>
> Due to hardcoded array size, GTM can not send to standby initial list of
> the defined sequences.
> So if GTM standby connects to GTM where more than 1024 sequences defined,
> it causes memory corruption and segmentation fault. Attached patch fixes
> the issue. It makes the array resizeable. For the same reason, client is
> modified to accept sequence list of any size.
>
> The patch applies to master and REL1_1_STABLE branches, there is separate
> patch for REL1_0_STABLE branch.
>
> --
> Andrei Martsinchyk
>
> StormDB - http://www.stormdb.com
> The Database Cloud
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>

Hi,

Have a Query about ExecRemoteQuery.

The logic seems to have been modeled after ExecMaterial. ISTM, that it
should have been modeled after ExecScan because we fetch tuples, and those
which match the qual should be sent up. ExecMaterial is for materializing
and collecting and storing tuples.

Can anyone explain? The reason for asking this is I am suspecting a big
memory leak in this code path. We are not using any expression context nor
we are freeing up tuples as we scan for the one which qualifies.

Regards,
Nikhils
-- 
StormDB - http://www.stormdb.com
The Database Cloud

PFA revised patch.


On Fri, Aug 9, 2013 at 9:31 AM, Masataka Saito <pg...@gm...> wrote:
> It will work. But it took a bit time to understand that
> selectSQL("testdate order by i", "dt")) is expanded to "SELECT dt FROM
> testdate order by i" because the first argument name of selectSQL is
> "table".
> You'd better use selectSQL (String table, String columns, String
> where, String other) rather than selectSQL(String table, String
> columns).
>
> On Thu, Aug 8, 2013 at 6:31 PM, Abbas Butt <abb...@en...> wrote:
>> Hi,
>> PFA patch to fix date tests needing order by.
>>
>> --
>> Abbas
>> Architect
>>
>> Ph: 92.334.5100153
>> Skype ID: gabbasb
>> www.enterprisedb.com
>>
>> Follow us on Twitter
>> @EnterpriseDB
>>
>> Visit EnterpriseDB for tutorials, webinars, whitepapers and more
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>



-- 
--
Abbas
Architect

Ph: 92.334.5100153
Skype ID: gabbasb
www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Fri, Aug 9, 2013 at 2:19 PM, Masataka Saito <pg...@gm...> wrote:
> On Thu, Aug 8, 2013 at 9:41 PM, Abbas Butt <abb...@en...> wrote:
>> Hi,
>> PFA patch to fix an XC limitation that update of a replicated table
>> created with oids cannot be based on oids.
>
> When did you change distribution rule to REPLICATION from ROUNDROBIN?
> I lost your patch.
>
>> i.e. this update supposed to fail
>> update rep_table_with_oids set colum = $1 where oid=$2
>> saying
>> ERROR : Write to replicated table returned different results from the Datanodes
>>
>> The reason is that we would select oid from the primary datanode and
>> that particular oid will not be there on the rest of the datanodes.
>> The patch comments explain the complete scenario in detail.
>>
>> With this patch the JDBC regression runs without any failures or
>> errors on my machine.
>> Strangely I did not have to change any thing on the server side.
>
> What do you experience the strangeness of?

I meant that none of the tests failing in JDBC test suite require any
change in the server, when this work was started we thought JDBC test
suite might uncover some bug in the server.

> Your patch eliminated "oid" column from the selection, therefore,
> UPDATE query does not contain "oid" anymore. I think it is
> straightforward.
>
> Regards.
>
>>
>> --
>> Abbas
>> Architect
>>
>> Ph: 92.334.5100153
>> Skype ID: gabbasb
>> www.enterprisedb.com
>>
>> Follow us on Twitter
>> @EnterpriseDB
>>
>> Visit EnterpriseDB for tutorials, webinars, whitepapers and more
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>



-- 
--
Abbas
Architect

Ph: 92.334.5100153
Skype ID: gabbasb
www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

PFA revised patch

On Fri, Aug 9, 2013 at 9:47 AM, Masataka Saito <pg...@gm...> wrote:
> My comment is same as the one for 10_1_date. patch.
>
> On Thu, Aug 8, 2013 at 6:32 PM, Abbas Butt <abb...@en...> wrote:
>> Hi,
>> PFA patch to fix time tests needing order by.
>>
>> --
>> Abbas
>> Architect
>>
>> Ph: 92.334.5100153
>> Skype ID: gabbasb
>> www.enterprisedb.com
>>
>> Follow us on Twitter
>> @EnterpriseDB
>>
>> Visit EnterpriseDB for tutorials, webinars, whitepapers and more
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>



-- 
--
Abbas
Architect

Ph: 92.334.5100153
Skype ID: gabbasb
www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars, whitepapers and more