From: Ashutosh B. <ash...@en...> - 2014-03-10 11:00:24
|
On Mon, Mar 10, 2014 at 2:54 PM, Pavan Deolasee <pav...@gm...>wrote: > > > > > On 10-Mar-2014, at 2:08 pm, Ashutosh Bapat < > ash...@en...> wrote: > > Here is another reason why we shouldn't add requirement for primary key in > replicated tables. Thanks Abbas for pointing it out. > > If the UPDATE/DELETE statement gets FQSed, we don't need a primary key for > replicated table and if it doesn't, then we need a primary key. It will be > difficult to explain users why some DMLs on replicated tables error out and > why some of them don't. > > > We should error out irrespective of whether the query can be FQSed or not. > > That's not what the patch is doing. Hence, my objection. Anyway, there is no reason for an FQSable DML not to be FQSed since there is no data corruption happening in that case. > Again we come back to the backward compatibility. > > > Again, it's a bug > > My objection is for the hasty fixes. We should fix the bug in a clean way without having any bad impacts. > Before anyone suggests, disabling FQS for replicated tables, is not a > solution here. It will affect performance badly. > > > IMHO correctness takes precedence over performance, especially now that we > are moving from being an experimental product to being production ready > > Well, try doing that, and people wouldn't use Postgres-XC :) > FWIW I am ok with adding a non documented guc for now > > Thanks, > Pavan > > > >> >> -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company |