On Wed, Dec 25, 2019 at 8:01 AM Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Dec 24, 2019 at 05:29:25PM +0530, Prabhat Sahu wrote: > While performing below operations with Master-Slave configuration, Slave is > crashed. > Below are the steps to reproduce: > > -- create a Slave using pg_basebackup and start: > ./pg_basebackup -v -R -D d2 -p 55510 > mkdir /home/centos/ts1 > > -- Session 1(Master): > ./psql postgres -p 55510 > > CREATE TABLESPACE ts1 location '/home/centos/ts1';
Your mistake is here. Both primary and standby are on the same host, so CREATE TABLESPACE would point to a path that overlap for both clusters as the tablespace path is registered the WAL replayed, leading to various weird behaviors. What you need to do instead is to create the tablespace before taking the base backup, and then take the base backup using pg_basebackup's --tablespace-mapping.
Thanks Michael for pointing it out, I have re-tested the scenario
with "--tablespace-mapping=OLDDIR=NEWDIR" option of pg_basebackup, and now its working fine.
But I think, instead of the crash, a proper error message would be better.
-- Michael
--
With Regards,
Prabhat Kumar Sahu Skype ID: prabhat.sahu1984 EnterpriseDB Software India Pvt. Ltd. The Postgres Database Company
From:
Michael Paquier Date: Subject:
Re: Assert failure due to "drop schema pg_temp_3 cascade" fortemporary tables and \d+ is not showing any info after drooping temp tableschema
Есть вопросы? Напишите нам!
Соглашаюсь с условиями обработки персональных данных
✖
By continuing to browse this website, you agree to the use of cookies. Go to Privacy Policy.