Re: pg_basebackup from 9.4-bdr to 9.4 results in corrupt index

Managed to find following in the announcement of BDR on 9.6:
"BDR has always been an extension, but *on 9.4 it required a heavily
patched PostgreSQL, one that isn’t fully on-disk-format compatible with
stock community PostgreSQL 9.4.* The goal all along has been to allow it to
run as an extension on an unmodified PostgreSQL … and now we’re there."

Source: https://www.2ndquadrant.com/en/blog/bdr-is-coming-to-postgresql-9-6/
I suppose this answers why logical dump / restore works, but pg_basebackup
fails - the stock 9.4 and BDR 9.4 are not compatible on disk level.

On 25 May 2019 at 23:26:26, Adrian Klaver (adrian(dot)klaver(at)aklaver(dot)com) wrote:

On 5/25/19 11:46 AM, Jānis Pūris wrote:
> Hi Ron,
>
> I can not reproduce this error on BDR_Node_2 (it is not BDR_Node_1 as
> stated before. Typo)
>
> I've been successful in transferring the data with pg_dump on BDR_Node_2
> and then restoring it on Regular_Node_1. Then running "select * from
> information_schema.sequences;" all is OK.

So the issue is that a binary backup/restore via pg_basebackup fails but
a logical backup/restore via pg_dump/pg_restore works, correct?

You might want to take a look here:

https://github.com/2ndQuadrant/bdr/issues/140

It might make sense to you, it does not to me. Looks to me something is
being done on the binary level that makes this difficult. I guessing you
are going to have to talk to the BDR folks.

>
> The problem with this approach is that I'm required to have minimal
> downtime in this transition and we have a lot of data to transfer, which
> would be lengthy process.
>
> Thank you in advance.
> Best regards, Janis Puris
>
> On 25 May 2019 at 19:16:11, Ron (ronljohnsonjr(at)gmail(dot)com
> <mailto:ronljohnsonjr(at)gmail(dot)com>) wrote:
>
>> 1. Are you sure that you removed all BDR from the node?
>> 2. Is the corruption there in BDR_Node_1?
>> 3. Can you rebuild the indexes?

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com