Re: Immediate standby promotion - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Immediate standby promotion
Date
Msg-id 2345.1408025537@sss.pgh.pa.us
Whole thread Raw
In response to Immediate standby promotion  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Immediate standby promotion
List pgsql-hackers
Fujii Masao <masao.fujii@gmail.com> writes:
> I'd like to propose to add new option "--immediate" to pg_ctl promote.
> When this option is set, recovery ignores any WAL data which have not
> been replayed yet and exits immediately. Patch attached.

> This promotion is faster than normal one but can cause data loss.

TBH, I cannot imagine a situation where that would be a sane thing to do.
If you have WAL, why would you not replay what you have?  The purpose
of a database is to preserve your data, not randomly throw it away.

> Also imagine the case
> where, while recovery is being delayed (by a time-delayed standby
> which was introduced in 9.4) or paused (by pg_xlog_replay_pause),
> you find that subsequent WAL data can cause a disaster to happen
> (for example, WAL data indicating an unexpected deletion of
> important database). In this case, this immediate promotion can be
> used to ignore such problematic WAL data.

That example does not demonstrate that a patch like this is useful.
What you'd presumably want is a way to stop replay at a defined place
(comparable to the PITR facilities).  Not to just abandon the WAL stream
at whatever point replay has reached.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: psql \watch versus \timing
Next
From: "Tomas Vondra"
Date:
Subject: Re: 9.5: Memory-bounded HashAgg