Possible bug in cascaded standby

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Possible bug in cascaded standby
Date: 2013-06-05 16:03:08
Message-ID: CABOikdN1=zjSL7U6ykzgia8ExPqLYfcBY2Pne__80CWVrrA11g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

I am experimenting with the cascade standby and hit a problem which is
reproducible with the current HEAD. I haven't tried other branches, but not
sure if the test setup I am trying even works for older releases because of
the timeline ID issue.

Anyways, I set up a cascaded standby such that it streams from the first
standby and then stopped the original master and promoted the first standby
to be the new master. If I then try to smart shutdown the cascaded standby,
it fails after waiting for the walreceiver to terminate. What's worse, the
walsender on the first standby gets into an infinite loop consuming 100%
CPU.

I tried to investigate this a bit, but haven't made progress worth
reporting. I can spend more time, but just wanted to make sure that I'm not
trying something which is a known issue or limitation. BTW, this is on my
Macbook Pro. Attached is the script that I used to set up the environment.
You will need to modify it for your setup though.

Thanks,
Pavan

--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

Attachment Content-Type Size
test_cascade_stdby.sh application/x-sh 1.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2013-06-05 16:12:47 Re: erroneous restore into pg_catalog schema
Previous Message Tom Lane 2013-06-05 15:45:11 Re: pg_rewind, a tool for resynchronizing an old master after failover