On 11.05.2011 08:29, Fujii Masao wrote:
On Sat, May 7, 2011 at 10:48 PM, Robert Haas<robertmh...@gmail.com> wrote:
I was able to reproduce something very like this in unpatched master,
just by letting recovery pause at a named restore point, and then
resuming it.
I was able to reproduce the same problem even in 9.0. When the standby
reaches the recovery target, it always tries to end the recovery even
though walreceiver is still running, which causes the problem. This seems
to be an oversight in streaming replication. I should have considered how
the standby should work when recovery_target is specified.
What about the attached patch? Which stops walreceiver instead of
emitting PANIC there only if we've reached the recovery target.
I think we can just always call ShutdownWalRcv(). It should be gone if
the server was promoted while streaming, but that's just an
implementation detail of what the promotion code does. There's no hard
reason why it shouldn't be running at that point anymore, as long as we
kill it before going any further.
Committed a patch to do that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
