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

> On 06-Mar-2014, at 7:57 am, Abbas Butt <abb...@en...> wrote:
> 
> 
> 
> 
>> On Wed, Mar 5, 2014 at 10:18 PM, Pavan Deolasee <pav...@gm...> wrote:
>>> On Wed, Mar 5, 2014 at 2:32 PM, Koichi Suzuki <koi...@gm...> wrote:
>>> I'd like Abbas to answer why it is practical at this point ...
>> 
>> Sure. I would wait for him to explain.
> 
> It was done as a quick fix for backward compatibility,

IMHO it's a bug that needs to be fixed and not a compatibility that needs to be backward supported. Let's just throw an error for now until we have time and resources to fix the bug.

Thanks,
Pavan

On Thu, Mar 6, 2014 at 5:52 AM, Koichi Suzuki <koi...@gm...> wrote:

> What we may be able to do for 1.2 is to add new GUC, say,
> require_replicated_table_pkey and set default to ON.   In regression,
> we set it OFF as we used to do for TEMP object with
> enforce_two_phase_commit.    This will be used when we support system
> pkey.
>
> Abbas, any input on this?
>

I agree with the GUC suggestion.


>
> ---
> Koichi Suzuki
>
>
> 2014-03-06 2:18 GMT+09:00 Pavan Deolasee <pav...@gm...>:
> > On Wed, Mar 5, 2014 at 2:32 PM, Koichi Suzuki <koi...@gm...>
> wrote:
> >>
> >> I'd like Abbas to answer why it is practical at this point ...
> >>
> >
> > Sure. I would wait for him to explain.
> >
> >>
> >> From the discussion of the thread, I understand that it is highly
> >> recommended to have a primary key in replicated tables.   This will be
> >> in the release note and the reference document.    Original patch from
> >> Mason requires a primary key, which causes some of regression test to
> >> fail and the short-term fix will make regression very dirty.
> >>
> >
> > I am sorry, but I think data inconsistency problem should take higher
> > priority that passing the regression tests. The regression tests are
> there
> > to find bugs, not hide them under the carpet. Even if its must for some
> > reason to temporarily circumvent the problem for the regression tests, a
> > possible way would be to test with a patched server. But I would strongly
> > argue against releasing anything which has a known and a very common data
> > corruption bug.
> >
> >>
> >> In a long run, as discussed, I believe system primary key will be a
> >> solution, if no primary key is defined as user column.
> >>
> >
> > Yeah, that would work. It should not be very complicated too to
> implement.
> >
> > Thanks,
> > Pavan
> >
> > --
> > Pavan Deolasee
> > http://www.linkedin.com/in/pavandeolasee
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&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.co
<http://www.enterprisedb.com/>m<http://www.enterprisedb.com/>

*Follow us on Twitter*
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars,
whitepapers<http://www.enterprisedb.com/resources-community>and
more<http://www.enterprisedb.com/resources-community>

On Wed, Mar 5, 2014 at 10:18 PM, Pavan Deolasee <pav...@gm...>wrote:

> On Wed, Mar 5, 2014 at 2:32 PM, Koichi Suzuki <koi...@gm...>wrote:
>
>> I'd like Abbas to answer why it is practical at this point ...
>>
>>
> Sure. I would wait for him to explain.
>

It was done as a quick fix for backward compatibility, later we may use
cursors or system generated primary key. We tried using cursors but that
work could not be completed in the allotted time.
It was also decided that since updates to replicated tables without unique
keys can cause issues we will add detailed information in docs/wiki/release
notes.


>
>> >From the discussion of the thread, I understand that it is highly
>> recommended to have a primary key in replicated tables.   This will be
>> in the release note and the reference document.    Original patch from
>> Mason requires a primary key, which causes some of regression test to
>> fail and the short-term fix will make regression very dirty.
>>
>>
> I am sorry, but I think data inconsistency problem should take higher
> priority that passing the regression tests. The regression tests are there
> to find bugs, not hide them under the carpet. Even if its must for some
> reason to temporarily circumvent the problem for the regression tests, a
> possible way would be to test with a patched server. But I would strongly
> argue against releasing anything which has a known and a very common data
> corruption bug.
>
>
>> In a long run, as discussed, I believe system primary key will be a
>> solution, if no primary key is defined as user column.
>>
>>
> Yeah, that would work. It should not be very complicated too to implement.
>
>
> Thanks,
> Pavan
>
> --
> Pavan Deolasee
> http://www.linkedin.com/in/pavandeolasee
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&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.co
<http://www.enterprisedb.com/>m<http://www.enterprisedb.com/>

*Follow us on Twitter*
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars,
whitepapers<http://www.enterprisedb.com/resources-community>and
more<http://www.enterprisedb.com/resources-community>

What we may be able to do for 1.2 is to add new GUC, say,
require_replicated_table_pkey and set default to ON.   In regression,
we set it OFF as we used to do for TEMP object with
enforce_two_phase_commit.    This will be used when we support system
pkey.

Abbas, any input on this?

---
Koichi Suzuki


2014-03-06 2:18 GMT+09:00 Pavan Deolasee <pav...@gm...>:
> On Wed, Mar 5, 2014 at 2:32 PM, Koichi Suzuki <koi...@gm...> wrote:
>>
>> I'd like Abbas to answer why it is practical at this point ...
>>
>
> Sure. I would wait for him to explain.
>
>>
>> From the discussion of the thread, I understand that it is highly
>> recommended to have a primary key in replicated tables.   This will be
>> in the release note and the reference document.    Original patch from
>> Mason requires a primary key, which causes some of regression test to
>> fail and the short-term fix will make regression very dirty.
>>
>
> I am sorry, but I think data inconsistency problem should take higher
> priority that passing the regression tests. The regression tests are there
> to find bugs, not hide them under the carpet. Even if its must for some
> reason to temporarily circumvent the problem for the regression tests, a
> possible way would be to test with a patched server. But I would strongly
> argue against releasing anything which has a known and a very common data
> corruption bug.
>
>>
>> In a long run, as discussed, I believe system primary key will be a
>> solution, if no primary key is defined as user column.
>>
>
> Yeah, that would work. It should not be very complicated too to implement.
>
> Thanks,
> Pavan
>
> --
> Pavan Deolasee
> http://www.linkedin.com/in/pavandeolasee

On Wed, Mar 5, 2014 at 2:32 PM, Koichi Suzuki <koi...@gm...> wrote:

> I'd like Abbas to answer why it is practical at this point ...
>
>
Sure. I would wait for him to explain.


> From the discussion of the thread, I understand that it is highly
> recommended to have a primary key in replicated tables.   This will be
> in the release note and the reference document.    Original patch from
> Mason requires a primary key, which causes some of regression test to
> fail and the short-term fix will make regression very dirty.
>
>
I am sorry, but I think data inconsistency problem should take higher
priority that passing the regression tests. The regression tests are there
to find bugs, not hide them under the carpet. Even if its must for some
reason to temporarily circumvent the problem for the regression tests, a
possible way would be to test with a patched server. But I would strongly
argue against releasing anything which has a known and a very common data
corruption bug.


> In a long run, as discussed, I believe system primary key will be a
> solution, if no primary key is defined as user column.
>
>
Yeah, that would work. It should not be very complicated too to implement.

Thanks,
Pavan

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

I'd like Abbas to answer why it is practical at this point ...

>From the discussion of the thread, I understand that it is highly
recommended to have a primary key in replicated tables.   This will be
in the release note and the reference document.    Original patch from
Mason requires a primary key, which causes some of regression test to
fail and the short-term fix will make regression very dirty.

In a long run, as discussed, I believe system primary key will be a
solution, if no primary key is defined as user column.

Regards;
---
Koichi Suzuki


2014-03-05 17:39 GMT+09:00 Pavan Deolasee <pav...@gm...>:
> Hi All,
>
> My apologies if I am raising a point which is well settled in other
> discussion. I know this topic has been discussed at length, but I haven't
> followed that discussion well. But the this statement in the commit log
> still worries me:
>
> "    Otherwise ctid is used, like we were using previously."
>
> This can never be safe for replicated tables. So why don't we just throw an
> error if no primary key or unique index is defined ? Updating tables based
> on ctid would definitely lead to data corruption. So why do that ?
>
> Thanks,
> Pavan
>
>
> ---------- Forwarded message ----------
> From: <ap...@us...>
> Date: Wed, Mar 5, 2014 at 1:51 PM
> Subject: [Postgres-xc-committers] Postgres-XC branch, REL1_2_STABLE,
> updated. XC1_0_BETA1_PG9_1-3999-ge5466f7
> To: pos...@li...
>
>
> Project "Postgres-XC".
>
> The branch, REL1_2_STABLE has been updated
>        via  e5466f780b3da3e44c5b65e245417db1af822af2 (commit)
>       from  45f8541d30cfd9f7385cd83c43bcdca813b7f83a (commit)
>
>
> - Log -----------------------------------------------------------------
> http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=e5466f780b3da3e44c5b65e245417db1af822af2
>
> commit 22fdd3506d5b3dd6a899b0e2134eb813b424c5db
> Author: Koichi Suzuki <koi...@gm...>
> Date:   Wed Mar 5 17:18:44 2014 +0900
>
>     A patch to improve replicated table update/delete handling.
>
>     This commit performs updates/deletes to replicated tables
>     based on either primary key or unique index under the following
>     conditions
>
>     1. The replicated table has either a primary key or a unique index
> defined.
>     2. The query is not changing the primary key itself.
>
>     Otherwise ctid is used, like we were using previously.
>
>
>
>
> --
> Pavan Deolasee
> http://www.linkedin.com/in/pavandeolasee
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

Hi All,

My apologies if I am raising a point which is well settled in other
discussion. I know this topic has been discussed at length, but I haven't
followed that discussion well. But the this statement in the commit log
still worries me:

"    Otherwise ctid is used, like we were using previously."

This can never be safe for replicated tables. So why don't we just throw an
error if no primary key or unique index is defined ? Updating tables based
on ctid would definitely lead to data corruption. So why do that ?

Thanks,
Pavan

---------- Forwarded message ----------
From: <ap...@us...>
Date: Wed, Mar 5, 2014 at 1:51 PM
Subject: [Postgres-xc-committers] Postgres-XC branch, REL1_2_STABLE,
updated. XC1_0_BETA1_PG9_1-3999-ge5466f7
To: pos...@li...


Project "Postgres-XC".

The branch, REL1_2_STABLE has been updated
       via  e5466f780b3da3e44c5b65e245417db1af822af2 (commit)
      from  45f8541d30cfd9f7385cd83c43bcdca813b7f83a (commit)


- Log -----------------------------------------------------------------
http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=commitdiff;h=e5466f780b3da3e44c5b65e245417db1af822af2

commit 22fdd3506d5b3dd6a899b0e2134eb813b424c5db
Author: Koichi Suzuki <koi...@gm...>
Date:   Wed Mar 5 17:18:44 2014 +0900

    A patch to improve replicated table update/delete handling.

    This commit performs updates/deletes to replicated tables
    based on either primary key or unique index under the following
    conditions

    1. The replicated table has either a primary key or a unique index
defined.
    2. The query is not changing the primary key itself.

    Otherwise ctid is used, like we were using previously.




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

Sakata-san;

I've tested the patch and found it does not apply to current
master/REL1_2_STABLE branch.   I also tested against REL1_1_STABLE and
the result was the same.   Could you check your patch against the
current repo?

I wonder why it happens because pgbench is very stable.    Maybe it
needs some tweak to deal with the current PG repo as well.

Could you also consider to use the format you get with "git diff"?

Thank you very much in advance.
---
Koichi Suzuki


2014-03-05 15:23 GMT+09:00 坂田　哲夫 <sak...@la...>:
> Hi, folks,
>
> I found a pgbench bug that pgbench fails to update tables such as
> pgbench_accounts and pgbench_tellers.
>
> For example, original pgbench for XC tries to update pgbench_accounts'
> specifying aid and bid values which are selected independently.
> By the pgbench's nature, bid should have a particular value for a
> given aid value. So the update statement fails picking up target
> tuple and updating the table in most cases.
>
> The attached patch, which should be applied to XC 1.1s
> pgbench, eliminates wrongly added bid specifications
> and corrects index and distribute settings related.
>
> Best regards,
>
> Tetsuo Sakata.
>
> --
> sakata.tetsuo _at_ lab.ntt.co.jp
> SAKATA, Tetsuo. Shinagawa Tokyo JAPAN.
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

Suzuki-san,

Thank you for your quick response.

I quickly checked pgbench included in XC 1.0.3 to find
this version does not have the problem I pointed out before.

So, you don't need apply that patch to the pgbench in XC 1.0.3.

** additional correction **

The patch I posted before does not have some corrections
for messages about "-k" option.
Now I send a newly created patch to supersede the predecessor.

Best Regards,

Tetsuo Sakata.


(2014/03/05 15:54), 鈴木 幸市 wrote:
> Sakata-san;
> 
> Thank you very much for the fix.    The patch looks to be applicable to 1.0..x as well.   Please let me know your thought.
> 
> Regards;
> ---
> Koichi Suzuki
> 
> 2014/03/05 15:23、坂田　哲夫 <sak...@la...> のメール：
> 
>> Hi, folks,
>>
>> I found a pgbench bug that pgbench fails to update tables such as
>> pgbench_accounts and pgbench_tellers.
>>
>> For example, original pgbench for XC tries to update pgbench_accounts'
>> specifying aid and bid values which are selected independently.
>> By the pgbench's nature, bid should have a particular value for a
>> given aid value. So the update statement fails picking up target
>> tuple and updating the table in most cases.
>>
>> The attached patch, which should be applied to XC 1.1s
>> pgbench, eliminates wrongly added bid specifications
>> and corrects index and distribute settings related.
>>
>> Best regards,
>>
>> Tetsuo Sakata.
>>
>> -- 
>> sakata.tetsuo _at_ lab.ntt.co.jp
>> SAKATA, Tetsuo. Shinagawa Tokyo JAPAN.
>> <pgbench_20140305.patch>------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries.  Built-in WAN optimization and the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg..clktrk_______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> 
> 
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> 


-- 
sakata.tetsuo _at_ lab.ntt.co.jp
SAKATA, Tetsuo. Shinagawa Tokyo JAPAN.

Sakata-san;

Thank you very much for the fix.    The patch looks to be applicable to 1.0..x as well.   Please let me know your thought.

Regards;
---
Koichi Suzuki

2014/03/05 15:23、坂田　哲夫 <sak...@la...> のメール：

> Hi, folks,
> 
> I found a pgbench bug that pgbench fails to update tables such as
> pgbench_accounts and pgbench_tellers.
> 
> For example, original pgbench for XC tries to update pgbench_accounts'
> specifying aid and bid values which are selected independently.
> By the pgbench's nature, bid should have a particular value for a
> given aid value. So the update statement fails picking up target
> tuple and updating the table in most cases.
> 
> The attached patch, which should be applied to XC 1.1s
> pgbench, eliminates wrongly added bid specifications
> and corrects index and distribute settings related.
> 
> Best regards,
> 
> Tetsuo Sakata.
> 
> -- 
> sakata.tetsuo _at_ lab.ntt.co.jp
> SAKATA, Tetsuo. Shinagawa Tokyo JAPAN.
> <pgbench_20140305.patch>------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works. 
> Faster operations. Version large binaries.  Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg..clktrk_______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

Hi, folks,

I found a pgbench bug that pgbench fails to update tables such as
pgbench_accounts and pgbench_tellers.

For example, original pgbench for XC tries to update pgbench_accounts'
specifying aid and bid values which are selected independently.
By the pgbench's nature, bid should have a particular value for a
given aid value. So the update statement fails picking up target
tuple and updating the table in most cases.

The attached patch, which should be applied to XC 1.1s
pgbench, eliminates wrongly added bid specifications
and corrects index and distribute settings related.

Best regards,

Tetsuo Sakata.

-- 
sakata.tetsuo _at_ lab.ntt.co.jp
SAKATA, Tetsuo. Shinagawa Tokyo JAPAN.

On Tue, Mar 4, 2014 at 10:27 PM, David E. Wheeler <da...@ju...>wrote:

> On Mar 3, 2014, at 8:45 PM, David E. Wheeler <da...@ju...>
> wrote:
>
> >> Although, it looks like the quals are shippable, there may be something
> which is being deemed as volatile (function or operator or a cast) or some
> parameter. Unfortunately, I don't have time to dig through it. Can you
> please check what happens to the JOIN if you say removing WHERE clause.
> With that the entire join should be shippable, assuming that the two
> relations are distributed on subscriber_id.
> >
> > config.subscribers is replicated to all nodes, and
> subscriber_482900.transactions is a partition, and the only subscriber_id
> in the whole table is 482900. It's distributed on another column,
> account_code. Taking out the WHERE clause is by definition a table scan:
>
> Sleeping on it, I realized that it might be thinking that the date math is
> volatile. So I tried a query using constant values, instead:
>
> =# EXPLAIN VERBOSE
> -# SELECT tr.subscriber_id  AS subscriber_id
> -#      , s.subscriber      AS subscriber_name
> -#      , tr.txn_id         AS tracking_number
> -#   FROM subscriber_:SUB_CODE.transactions tr
> -#   LEFT JOIN config.subscribers s ON tr.subscriber_id = s.subscriber_id
> -#  WHERE tr.subscriber_id = :SUB_CODE
> -#    AND  tr.txn_timestamp_utc >= '2014-01-15'::timestamp
> -#    AND  tr.txn_timestamp_utc < '2014-01-16'::timestamp
> -# ;
>
>
>                                                      QUERY PLAN
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  Data Node Scan on "__REMOTE_FQS_QUERY__"  (cost=0.00..0.00 rows=0 width=0)
>    Output: tr.subscriber_id, s.subscriber, tr.txn_id
>    Node/s: rptdata01, rptdata02, rptdata03, rptdata04
>    Remote query: SELECT tr.subscriber_id, s.subscriber AS subscriber_name,
> tr.txn_id AS tracking_number FROM (subscriber_482900.transactions tr LEFT
> JOIN config.subscribers s ON ((tr.subscriber_id = s.subscriber_id))) WHERE
> (((tr.subscriber_id = 482900) AND (tr.txn_timestamp_utc >= '2014-01-15
> 00:00:00'::timestamp without time zone)) AND (tr.txn_timestamp_utc <
> '2014-01-16 00:00:00'::timestamp without time zone))
> (4 rows)
>
> That's *so* much better. Makes me realize we probably have the same
> problem in the original Postgres version of this query.
>
>
Good, that's what I was pointing to in my earlier mail. Since the quals are
not shippable because of the volatility, the LEFT join too is not
shippable. Notice that PostgreSQL planner has pushed those quals down to
the respective relation.

BTW, I am still not able to spot the volatility in those quals, but that's
a different question, I think.


> Thanks,
>
> David
>
>


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

On Mar 3, 2014, at 8:45 PM, David E. Wheeler <da...@ju...> wrote:

>> Although, it looks like the quals are shippable, there may be something which is being deemed as volatile (function or operator or a cast) or some parameter. Unfortunately, I don't have time to dig through it. Can you please check what happens to the JOIN if you say removing WHERE clause. With that the entire join should be shippable, assuming that the two relations are distributed on subscriber_id.
> 
> config.subscribers is replicated to all nodes, and subscriber_482900.transactions is a partition, and the only subscriber_id in the whole table is 482900. It's distributed on another column, account_code. Taking out the WHERE clause is by definition a table scan:

Sleeping on it, I realized that it might be thinking that the date math is volatile. So I tried a query using constant values, instead:

=# EXPLAIN VERBOSE
-# SELECT tr.subscriber_id  AS subscriber_id
-#      , s.subscriber      AS subscriber_name
-#      , tr.txn_id         AS tracking_number
-#   FROM subscriber_:SUB_CODE.transactions tr
-#   LEFT JOIN config.subscribers s ON tr.subscriber_id = s.subscriber_id
-#  WHERE tr.subscriber_id = :SUB_CODE
-#    AND  tr.txn_timestamp_utc >= '2014-01-15'::timestamp
-#    AND  tr.txn_timestamp_utc < '2014-01-16'::timestamp
-# ;
                                                                                                                                                                                                           QUERY PLAN                                                                                                                                                                                                           
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Data Node Scan on "__REMOTE_FQS_QUERY__"  (cost=0.00..0.00 rows=0 width=0)
   Output: tr.subscriber_id, s.subscriber, tr.txn_id
   Node/s: rptdata01, rptdata02, rptdata03, rptdata04
   Remote query: SELECT tr.subscriber_id, s.subscriber AS subscriber_name, tr.txn_id AS tracking_number FROM (subscriber_482900.transactions tr LEFT JOIN config.subscribers s ON ((tr.subscriber_id = s.subscriber_id))) WHERE (((tr.subscriber_id = 482900) AND (tr.txn_timestamp_utc >= '2014-01-15 00:00:00'::timestamp without time zone)) AND (tr.txn_timestamp_utc < '2014-01-16 00:00:00'::timestamp without time zone))
(4 rows)

That’s *so* much better. Makes me realize we probably have the same problem in the original Postgres version of this query.

Thanks,

David

Don't worry,  GUC is available.    I only enabled TEMP objects in implicit 2PC.

Regards;
---
Koichi Suzuki


2014-03-04 13:13 GMT+09:00 Ashutosh Bapat <ash...@en...>:
> Hi Suzuki-san,
> Did you remove the GUC too?
>
>
> On Tue, Mar 4, 2014 at 7:14 AM, Repository Postgres-XC postgres-xc.git
> <no...@po...> wrote:
>>
>> master: Improvement of the regression to use TEMP object in implicit 2PCs.
>>
>> Now all "SET enforce_two_phase_commit TO OFF" and relevant lines are
>> removed and Temporary objects are used in implicit 2PC.
>>
>> http://sourceforge.net/p/postgres-xc/postgres-xc/ci/c049a4390b9ae705717f37590e844f72ddec3ceb/
>>
>> ________________________________
>>
>> Sent from sourceforge.net because you indicated interest in
>> https://sourceforge.net/p/postgres-xc/postgres-xc/
>>
>> To unsubscribe from further messages, please visit
>> https://sourceforge.net/auth/subscriptions/
>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EnterpriseDB Corporation
> The Postgres Database Company
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

On Mar 3, 2014, at 7:50 PM, Ashutosh Bapat <ash...@en...> wrote:

> Although, it looks like the quals are shippable, there may be something which is being deemed as volatile (function or operator or a cast) or some parameter. Unfortunately, I don't have time to dig through it. Can you please check what happens to the JOIN if you say removing WHERE clause. With that the entire join should be shippable, assuming that the two relations are distributed on subscriber_id.

config.subscribers is replicated to all nodes, and subscriber_482900.transactions is a partition, and the only subscriber_id in the whole table is 482900. It's distributed on another column, account_code. Taking out the WHERE clause is by definition a table scan:

=# EXPLAIN VERBOSE
-# SELECT tr.subscriber_id  AS subscriber_id
-#      , s.subscriber      AS subscriber_name
-#      , tr.txn_id         AS tracking_number
-#   FROM subscriber_:SUB_CODE.transactions tr
-#   LEFT JOIN config.subscribers s ON tr.subscriber_id = s.subscriber_id
-#  WHERE tr.subscriber_id = :SUB_CODE
-#    AND  tr.txn_timestamp_utc >= :'RPT_DAY'::timestamp - (:DAYS_BACK || ' days')::interval + (:CUTOFF_HOUR || ' hours')::interval
-#    AND  tr.txn_timestamp_utc< :'RPT_DAY'::timestamp  + (:CUTOFF_HOUR || ' hours')::interval
-# ;
                                                                                                                                            QUERY PLAN                                                                                                                                            
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=0.00..0.01 rows=1 width=44)
   Output: tr.subscriber_id, s.subscriber, tr.txn_id
   Join Filter: (tr.subscriber_id = s.subscriber_id)
   ->  Data Node Scan on transactions "_REMOTE_TABLE_QUERY_"  (cost=0.00..0.00 rows=1000 width=12)
         Output: tr.subscriber_id, tr.txn_id
         Node/s: rptdata01, rptdata02, rptdata03, rptdata04
         Remote query: SELECT subscriber_id, txn_id, txn_timestamp_utc FROM ONLY subscriber_482900.transactions tr WHERE (subscriber_id = 482900)
         Coordinator quals: ((tr.txn_timestamp_utc < ('2014-01-16 00:00:00'::timestamp without time zone + ('0 hours'::cstring)::interval)) AND (tr.txn_timestamp_utc >= (('2014-01-16 00:00:00'::timestamp without time zone - ('1 days'::cstring)::interval) + ('0 hours'::cstring)::interval)))
   ->  Data Node Scan on subscribers "_REMOTE_TABLE_QUERY_"  (cost=0.00..0.00 rows=1000 width=36)
         Output: s.subscriber, s.subscriber_id
         Node/s: rptdata01
         Remote query: SELECT subscriber, subscriber_id FROM ONLY config.subscribers s WHERE (subscriber_id = 482900)

David

Hi Suzuki-san,
Did you remove the GUC too?


On Tue, Mar 4, 2014 at 7:14 AM, Repository Postgres-XC postgres-xc.git <
no...@po...> wrote:

> master: Improvement of the regression to use TEMP object in implicit 2PCs.
>
> Now all "SET enforce_two_phase_commit TO OFF" and relevant lines are
> removed and Temporary objects are used in implicit 2PC.
>
> http://sourceforge.net/p/postgres-xc/postgres-xc/ci/c049a4390b9ae705717f37590e844f72ddec3ceb/
> ------------------------------
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/postgres-xc/postgres-xc/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>



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

On Tue, Mar 4, 2014 at 1:30 AM, David E. Wheeler <da...@ju...>wrote:

> On Mar 3, 2014, at 10:36 AM, David E. Wheeler <da...@ju...>
> wrote:
>
> > Even with JOIN clauses added to the query such that it *should* run in
> whole on each node, the plan still fetches an entire (very large) table
> from each node. I will keep fiddling with the query to see if I can figure
> out how to get it to run on the nodes.
>
> Okay, here's a simplified example:
>
> =# EXPLAIN VERBOSE
> SELECT tr.subscriber_id  AS subscriber_id
>      , s.subscriber      AS subscriber_name
>      , tr.txn_id         AS tracking_number
>   FROM subscriber_:SUB_CODE.transactions tr
>   LEFT JOIN config.subscribers s ON tr.subscriber_id = s.subscriber_id
>  WHERE  tr.txn_timestamp_utc >= :'RPT_DAY'::timestamp - (:DAYS_BACK || '
> days')::interval + (:CUTOFF_HOUR || ' hours')::interval
>    AND  tr.txn_timestamp_utc< :'RPT_DAY'::timestamp  + (:CUTOFF_HOUR || '
> hours')::interval
> ;
>
>                                                                      QUERY
> PLAN
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  Hash Right Join  (cost=0.01..0.06 rows=1 width=44)
>    Output: tr.subscriber_id, s.subscriber, tr.txn_id
>    Hash Cond: (s.subscriber_id = tr.subscriber_id)
>    ->  Data Node Scan on subscribers "_REMOTE_TABLE_QUERY_"
>  (cost=0.00..0.00 rows=1000 width=36)
>          Output: s.subscriber, s.subscriber_id
>          Node/s: rptdata01
>          Remote query: SELECT subscriber, subscriber_id FROM ONLY
> config.subscribers s WHERE true
>    ->  Hash  (cost=0.00..0.00 rows=1000 width=12)
>          Output: tr.subscriber_id, tr.txn_id
>          ->  Data Node Scan on transactions "_REMOTE_TABLE_QUERY_"
>  (cost=0.00..0.00 rows=1000 width=12)
>                Output: tr.subscriber_id, tr.txn_id
>                Node/s: rptdata01, rptdata02, rptdata03, rptdata04
>                Remote query: SELECT subscriber_id, txn_id,
> txn_timestamp_utc FROM ONLY subscriber_482900.transactions tr WHERE true
>                Coordinator quals: ((tr.txn_timestamp_utc < ('2014-01-16
> 00:00:00'::timestamp without time zone + ('0 hours'::cstring)::interval))
> AND (tr.txn_timestamp_utc >= (('2014-01-16 00:00:00'::timestamp without
> time zone - ('1 days'::cstring)::interval) + ('0
> hours'::cstring)::interval)))
>
> This line is the problem:
>
>     Remote query: SELECT subscriber_id, txn_id, txn_timestamp_utc FROM
> ONLY subscriber_482900.transactions tr WHERE true
>
> Why aren't the WHERE clauses getting pushed down to the data nodes? That
> transactions table is very large, and there is an index on
> txn_timestamp_utc, so I can see no reason why the planner would choose to
> do a full table scan on every data node and filter on the coordinator.
> That's a really poor choice. This forced table scan is eating all the
> memory, of course.
>
> Is there a reason the planner isn't pushing down the WHERE clauses?
>
>
Although, it looks like the quals are shippable, there may be something
which is being deemed as volatile (function or operator or a cast) or some
parameter. Unfortunately, I don't have time to dig through it. Can you
please check what happens to the JOIN if you say removing WHERE clause.
With that the entire join should be shippable, assuming that the two
relations are distributed on subscriber_id.


> Thanks,
>
> David
>
>


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

On Mar 3, 2014, at 10:36 AM, David E. Wheeler <da...@ju...> wrote:

> Even with JOIN clauses added to the query such that it *should* run in whole on each node, the plan still fetches an entire (very large) table from each node. I will keep fiddling with the query to see if I can figure out how to get it to run on the nodes.

Okay, here’s a simplified example:

=# EXPLAIN VERBOSE
SELECT tr.subscriber_id  AS subscriber_id
     , s.subscriber      AS subscriber_name
     , tr.txn_id         AS tracking_number
  FROM subscriber_:SUB_CODE.transactions tr
  LEFT JOIN config.subscribers s ON tr.subscriber_id = s.subscriber_id
 WHERE  tr.txn_timestamp_utc >= :'RPT_DAY'::timestamp - (:DAYS_BACK || ' days')::interval + (:CUTOFF_HOUR || ' hours')::interval
   AND  tr.txn_timestamp_utc< :'RPT_DAY'::timestamp  + (:CUTOFF_HOUR || ' hours')::interval
;
                                                                                                                                               QUERY PLAN                                                                                                                                               
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Hash Right Join  (cost=0.01..0.06 rows=1 width=44)
   Output: tr.subscriber_id, s.subscriber, tr.txn_id
   Hash Cond: (s.subscriber_id = tr.subscriber_id)
   ->  Data Node Scan on subscribers "_REMOTE_TABLE_QUERY_"  (cost=0.00..0.00 rows=1000 width=36)
         Output: s.subscriber, s.subscriber_id
         Node/s: rptdata01
         Remote query: SELECT subscriber, subscriber_id FROM ONLY config.subscribers s WHERE true
   ->  Hash  (cost=0.00..0.00 rows=1000 width=12)
         Output: tr.subscriber_id, tr.txn_id
         ->  Data Node Scan on transactions "_REMOTE_TABLE_QUERY_"  (cost=0.00..0.00 rows=1000 width=12)
               Output: tr.subscriber_id, tr.txn_id
               Node/s: rptdata01, rptdata02, rptdata03, rptdata04
               Remote query: SELECT subscriber_id, txn_id, txn_timestamp_utc FROM ONLY subscriber_482900.transactions tr WHERE true
               Coordinator quals: ((tr.txn_timestamp_utc < ('2014-01-16 00:00:00'::timestamp without time zone + ('0 hours'::cstring)::interval)) AND (tr.txn_timestamp_utc >= (('2014-01-16 00:00:00'::timestamp without time zone - ('1 days'::cstring)::interval) + ('0 hours'::cstring)::interval)))

This line is the problem:

    Remote query: SELECT subscriber_id, txn_id, txn_timestamp_utc FROM ONLY subscriber_482900.transactions tr WHERE true

Why aren't the WHERE clauses getting pushed down to the data nodes? That transactions table is very large, and there is an index on txn_timestamp_utc, so I can see no reason why the planner would choose to do a full table scan on every data node and filter on the coordinator. That’s a really poor choice. This forced table scan is eating all the memory, of course.

Is there a reason the planner isn’t pushing down the WHERE clauses?

Thanks,

David

On Mar 3, 2014, at 10:02 AM, David E. Wheeler <da...@ju...> wrote:

> The query I’m running has EXPLAIN VERBOSE, not EXPLAIN ANALYZE. Is the parser mucking with it somehow? This is 1.1. 

Crap, just realized that I have two query files. I was editing one and running the other. Sheesh, sorry about that.

Even with JOIN clauses added to the query such that it *should* run in whole on each node, the plan still fetches an entire (very large) table from each node. I will keep fiddling with the query to see if I can figure out how to get it to run on the nodes.

> The possibility of corrupted shared memory is distressing; wish the log would say which node exited abnormally.

This is a pretty significant issue, though. The thing really should not run out of memory, and even it it does, it should tell me where.

Thanks,

David

On Feb 28, 2014, at 8:23 PM, Ashutosh Bapat <ash...@en...> wrote:

> This looks weird. Are you seeing this error in datanode logs or coordinator logs. For mere EXPLAIN only coordinator is active. Coordinator and datanode are not connected. So, if you are seeing disconnection error on datanode when you fired EXPLAIN VERBOSE on coordinator, that's weird. Am I missing something?

The error is in the data node logs. The coordinator has this:

2014-03-03 09:21:43 PST   22325 530659c2.5735 LOG:  server process (PID 24475) was terminated by signal 9: Killed
2014-03-03 09:21:43 PST   22325 530659c2.5735 DETAIL:  Failed process was running: EXPLAIN ANALYZE
	WITH DTL1 as
	(Select
	         td.subscriber_id,
	         s.subscriber::varchar(40) as subscriber_name,
	         td.txn_id::char(20) as tracking_number,
	         to_char(td.txn_timestamp_local,'yyyy/mm/dd-hh24:mi:ss')::varchar(50) as transaction_time_local,
	        to_char(td.txn_timestamp_utc,'yyyy/mm/dd-hh24:mi:ss')::varchar(50) as transaction_time,
	         td.local_timezone as local_timezone,
	         td.account_code::varchar(60),
	        case  when td.account_code is not null
	    then valueof_node_id(node_id_to_string( node_id( subscriber_id := s.subscriber_id, account_code := td.account_code)))::varchar(80)
	    else null::varchar(80) end as account_link,
	         td.device_id::char(20) as device_id,
	         CASE
	            WHEN td.result_code = 0 THEN 'Allow'::varchar(10)
	            WHEN td.result_code = 1 THEN 'Deny'::varchar(10)
	            WHEN td.result_code = 2 THEN 'Review'::varchar(10)
	            ELSE 'Other'::varchar(10)
	           END  as result,
	         td.ruleset,
	       
2014-03-03 09:21:43 PST   22325 530659c2.5735 LOG:  terminating any other active server processes
2014-03-03 09:21:44 PST   9611 53110262.258b WARNING:  terminating connection because of crash of another server process
2014-03-03 09:21:44 PST   9611 53110262.258b DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2014-03-03 09:21:44 PST   9611 53110262.258b HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2014-03-03 09:21:44 PST   22325 530659c2.5735 LOG:  all server processes terminated; reinitializing
2014-03-03 09:21:48 PST   26198 5314ba2c.6656 LOG:  database system was interrupted; last known up at 2014-03-03 09:16:56 PST
2014-03-03 09:21:48 PST   26198 5314ba2c.6656 LOG:  database system was not properly shut down; automatic recovery in progress
2014-03-03 09:21:48 PST   26198 5314ba2c.6656 LOG:  redo starts at 0/2F47B70
2014-03-03 09:21:48 PST   26198 5314ba2c.6656 LOG:  record with zero length at 0/2F47D50
2014-03-03 09:21:48 PST   26198 5314ba2c.6656 LOG:  redo done at 0/2F47D20
2014-03-03 09:21:48 PST   26198 5314ba2c.6656 LOG:  last completed transaction was at log time 2014-03-03 17:21:13.279991+00
2014-03-03 09:21:48 PST   26202 5314ba2c.665a LOG:  autovacuum launcher started
2014-03-03 09:21:48 PST   22325 530659c2.5735 LOG:  database system is ready to accept connections

The query I’m running has EXPLAIN VERBOSE, not EXPLAIN ANALYZE. Is the parser mucking with it somehow? This is 1.1. 

The possibility of corrupted shared memory is distressing; wish the log would say which node exited abnormally.

David

Unfortunately, Savepoint is not in the roadmap yet.    When a transaction needs new connection to other node, it must export existing Savepoints and also we need to handle unnamed savepoints as used in plpgsql.

Temporary object fix was much simpler.    In essence, I needed to change only three lines of code.

Welcome if anybody can help to support the savepoint.

Regards;
---
Koichi Suzuki

2014/03/01 2:05、David E. Wheeler <da...@ju...> のメール：

> On Feb 27, 2014, at 10:51 PM, 鈴木 幸市 <ko...@in...> wrote:
> 
>> Sorry, it has not been made open.    Similar to PG, I’m planning to release 1.0.3 and 1.1.1 after 1.2GA is out.   1.2GA will be out when replicated table update/delete is fixed.
> 
> Ah-ha, okay, thank you for the clarification.
> 
>>  I’m planning to include the following fixes in all the major/minor releases.
>> 
>> 1. GTM Proxy fix to handle disconnection from backends:  this caused “snapshot not available” error for heavy workloads.
>> 2. Fix restriction to use temporary objects.
>> 3. Fix statement cancellation error to improve random failure in the regression test.
> 
> These sound like useful improvements. The temporary object fix will be particularly welcome.
> 
> Can you tell me where savepoint support is in your roadmap?
> 
> Thanks,
> 
> David
> 
> 

On Sat, Mar 1, 2014 at 2:47 AM, David E. Wheeler <da...@ju...>wrote:

> On Feb 27, 2014, at 7:48 PM, Ashutosh Bapat <
> ash...@en...> wrote:
>
> > It might be due to the large amount of data sent from the datanode to
> the connector. When you see message "connection to client lost" at
> datanode, it means that the connection to the coordinator was lost. In XC,
> coordinators act as client to the datanode. Further, no message in the
> coordinator log implies that there wasn't any segfault or error on the
> coordinator which can result in loosing client (to the datanode). One way
> to verify this is to check what happens for smaller amounts of the data.
> There is still some code in executor, which saves data from datanode in a
> linked list and because of large amount of data that process runs out of
> memory. You may find something in system logs, if that is true.
>
> Ah ha. Now that I pay more attention to the statement in the log, I see
> what the problem is. That's a full table scan it's doing, on a very large
> table. I think the planner is making a mistake. The query I'm running is
> far more complicated than that bit in the log. Really, the full query
> should be able to run on each node, and the results aggregated on the
> coordinator. I suspect I need to add some more JOIN clauses to make sure
> that the planner better knows how to run the query on each node.
>
> > Please do the following,
> > Run explain verbose on the query which showed this behavior and in that
> output you will find what query is being sent to the datanode
>
> So I did this, but even with the EXPLAIN VERBOSE I got the disconnect
> error. With plain EXPLAIN, too. The query should not run without ANALZYE,
> right? This is 1.1, BTW.
>

This looks weird. Are you seeing this error in datanode logs or coordinator
logs. For mere EXPLAIN only coordinator is active. Coordinator and datanode
are not connected. So, if you are seeing disconnection error on datanode
when you fired EXPLAIN VERBOSE on coordinator, that's weird. Am I missing
something?


>
> > Reduce your data on the datanode such that, that particular query
> returns may be a few thousand rows to the coordinator. BTW, I have seen
> millions of rows being exchanged between the coordinator and datanode
> without problem. But still there is a case where large data would be a
> problem.
> > Now, see if the query runs without problem.
>
> I updated my query to make sure that I was joining on partitioned columns,
> thinking that would get the queries to run more on the data nodes, but it
> made no difference. I still got an error for a table scan on a very large
> table. :-(
>
> David
>
>


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

On Feb 27, 2014, at 7:48 PM, Ashutosh Bapat <ash...@en...> wrote:

> It might be due to the large amount of data sent from the datanode to the connector. When you see message "connection to client lost" at datanode, it means that the connection to the coordinator was lost. In XC, coordinators act as client to the datanode. Further, no message in the coordinator log implies that there wasn't any segfault or error on the coordinator which can result in loosing client (to the datanode). One way to verify this is to check what happens for smaller amounts of the data. There is still some code in executor, which saves data from datanode in a linked list and because of large amount of data that process runs out of memory. You may find something in system logs, if that is true.

Ah ha. Now that I pay more attention to the statement in the log, I see what the problem is. That's a full table scan it's doing, on a very large table. I think the planner is making a mistake. The query I'm running is far more complicated than that bit in the log. Really, the full query should be able to run on each node, and the results aggregated on the coordinator. I suspect I need to add some more JOIN clauses to make sure that the planner better knows how to run the query on each node.

> Please do the following,
> Run explain verbose on the query which showed this behavior and in that output you will find what query is being sent to the datanode

So I did this, but even with the EXPLAIN VERBOSE I got the disconnect error. With plain EXPLAIN, too. The query should not run without ANALZYE, right? This is 1.1, BTW.

> Reduce your data on the datanode such that, that particular query returns may be a few thousand rows to the coordinator. BTW, I have seen millions of rows being exchanged between the coordinator and datanode without problem. But still there is a case where large data would be a problem.
> Now, see if the query runs without problem.

I updated my query to make sure that I was joining on partitioned columns, thinking that would get the queries to run more on the data nodes, but it made no difference. I still got an error for a table scan on a very large table. :-(

David

On Feb 27, 2014, at 10:51 PM, 鈴木 幸市 <ko...@in...> wrote:

> Sorry, it has not been made open.    Similar to PG, I’m planning to release 1.0.3 and 1.1.1 after 1.2GA is out.   1.2GA will be out when replicated table update/delete is fixed.

Ah-ha, okay, thank you for the clarification.

>   I’m planning to include the following fixes in all the major/minor releases.
> 
> 1. GTM Proxy fix to handle disconnection from backends:  this caused “snapshot not available” error for heavy workloads.
> 2. Fix restriction to use temporary objects.
> 3. Fix statement cancellation error to improve random failure in the regression test.

These sound like useful improvements. The temporary object fix will be particularly welcome.

Can you tell me where savepoint support is in your roadmap?

Thanks,

David

Sorry, it has not been made open.    Similar to PG, I’m planning to release 1.0.3 and 1.1.1 after 1.2GA is out.   1.2GA will be out when replicated table update/delete is fixed.   I’m planning to include the following fixes in all the major/minor releases.

1. GTM Proxy fix to handle disconnection from backends:  this caused “snapshot not available” error for heavy workloads.
2. Fix restriction to use temporary objects.
3. Fix statement cancellation error to improve random failure in the regression test.

Regards;
---
Koichi Suzuki

2014/02/28 8:33、David E. Wheeler <da...@ju...> のメール：

> On Feb 27, 2014, at 3:29 PM, Koichi Suzuki <koi...@gm...> wrote:
> 
>> It is not correct.  1.0  and 1.1 are maintained.    Fix of the issue may not be easy though.
> 
> So, maintained, but no plan to release new versions? Sure, some bugs may be too much trouble for a maintained branch, but as Abbas says there are no plans to release new versions, it sounds an awful lot to me like no issues will be fixed, at least not in a release.
> 
> Best,
> 
> David
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>