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

[Koichi S. <koi...@gm...>]

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