Re: [Postgres-xc-developers] Fwd: [Postgres-xc-committers] Postgres-XC branch, REL1_2_STABLE, updated. XC1_0_BETA1_PG9_1-3999-ge5466f7

[Abbas B. <abb...@en...>]

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>