From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Immediate standby promotion |
Date: | 2014-08-14 14:12:17 |
Message-ID: | 2345.1408025537@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fujii Masao <masao(dot)fujii(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2014-08-14 14:17:47 | Re: 9.5: Memory-bounded HashAgg |
Previous Message | Fujii Masao | 2014-08-14 14:10:01 | Re: psql \watch versus \timing |