Re: BDR to ignore table exists error

From: Nikhil <nikhilsmenon(at)gmail(dot)com>
To: Martín Marqués <martin(at)2ndquadrant(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: BDR to ignore table exists error
Date: 2016-05-31 10:39:22
Message-ID: CALo-6YPhuOvHnr_gqS4RP0Cb9QxoL3RDPAeBPaW0MVnr3LSGVg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks a lot Martin for your replies.

On Sun, May 29, 2016 at 11:50 PM, Martín Marqués <martin(at)2ndquadrant(dot)com>
wrote:

> Hi,
>
> El 29/05/16 a las 06:01, Nikhil escribió:
> >
> > *​Nik>> skip_ddl_locking is set to True in my configuration. As this
> > was preventing single*
> >
> > *​node from doing DDL operation (if one is down majority is not there
> > for doing DDL on available node)*​
>
> Well, you have to be prepared to deal with burn wounds if you play with
> fire. ;)
>
> If you decide to have skip_ddl_locking on you have to be sure all DDLs
> happen on one node, else you end up with conflicts like this.
>
> I suggest you find out why the table was already created on the
> downstream node (as a forensics task so you can avoid bumping into the
> same issue).
>
> > ​Nik>> DDL used is
> >
> > ​
> > ERROR: relation "af_npx_l3_16_146_10" already exists
> > <596802016-05-29 08:53:07 GMT%CONTEXT: during DDL replay of ddl
> > statement: CREATE TABLE public.af_npx_license_l3_16_146_
> > 10 (CONSTRAINT af_npx_license_l3_16_146_10_rpt_sample_time_check CHECK
> > (((rpt_sample_time OPERATOR(pg_catalog.>=) 146417040
> > 0) AND (rpt_sample_time OPERATOR(pg_catalog.<=) 1464173999))) ) INHERITS
> > (public.af_npx_l3) WITH (oids=OFF)
> > <554132016-05-29 08:53:07 GMT%LOG: worker process: bdr
> > (6288512113617339435,2,16384,)->bdr (6288505144157102317,1, (PID 59
> > 680) exited with exit code 1
>
> On the node where the CREATE TABLE is trying to get applied run this:
>
> BEGIN;
> SET LOCAL bdr.skip_ddl_replication TO 'on';
> SET LOCAL bdr.skip_ddl_locking TO 'on';
> DROP TABLE af_npx_l3_16_146_10;
> END;
>
> After that, the DDL that's stuck will get applied and the stream of
> changes will continue.
>
> By the looks of what you're dealing with, I wouldn't be surprised if the
> replication gets stuck again on another DDL conflict.
>
> I suggest rethinking the locking strategy, because this shows that
> there's something fishy there.
>
> Regards,
>
> --
> Martín Marqués http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message hubert depesz lubaczewski 2016-05-31 10:53:24 Re: swarm of processes in BIND state?
Previous Message Szymon Lipiński 2016-05-31 10:33:08 Re: How to hide JDBC connection credentials from git?