On 02/04/2019 14:59, Tom Lane wrote: > Well, that's not much help :-(. Can you provide any info to narrow > down where this is happening? I mean, you haven't even told us whether > it's the primary or the slave that is complaining. Does it seem to > be associated with any particular command? (Turning on log_statement > and/or log_replication_commands would likely help with that.) Does > data seem to be getting transferred despite the complaint? If not, > what's missing on the slave? > > regards, tom lane I've been working to narrow it, the error is being reported on the slave. The only schema changes have been the two primary keys added to two tables. The problem occurred during this cycle: 1) Replication proceeding fine for ~380 tables, all added individually not "all tables". 2) Add primary key on master. 3) Add primary key on slave. 4) Refresh subscription on slave; error starts being reported. I've cleared it by dropping the slave database, re-creating from the live schema then fully replicating. Its all running happily now. Tim Clarke Main: +44 (0)1376 503500 | Fax: +44 (0)1376 503550 Web: https://www.manifest.co.uk/ Minerva Analytics Ltd 9 Freebournes Court | Newland Street | Witham | Essex | CM8 2BL | England ---------------------------------------------------------------------------------------------------------------------------- Copyright: This e-mail may contain confidential or legally privileged information. If you are not the named addressee you must not use or disclose such information, instead please report it to admin@xxxxxxxxxxxx<mailto:admin@xxxxxxxxxxxx> Legal: Minerva Analytics is the trading name of: Minerva Analytics Ltd: Registered in England Number 11260966 & The Manifest Voting Agency Ltd: Registered in England Number 2920820 Registered Office at above address. Please Click Here >><https://www.manifest.co.uk/legal/> for further information.
