On Wed, Sep 17, 2014 at 7:23 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 14 August 2014 20:27, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Aug 14, 2014 at 10:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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.
>>
>> I've wanted this a number of times, so I think it's quite sane.
>
> "fast" promotion was actually a supported option in r8 of Postgres but
> this option was removed when we implemented streaming replication in
> r9.0
>
> The *rough* requirement is sane, but that's not the same thing as
> saying this exact patch makes sense.
Granted. Fair point.
> If you are paused and you can see that WAL up ahead is damaged, then
> YES, you do want to avoid applying it. That is possible by setting a
> PITR target so that recovery stops at a precise location specified by
> you. As an existing option is it better than the blunt force trauma
> suggested here.
You can pause at a recovery target, but then what if you want to go
read/write at that point? Or what if you've got a time-delayed
standby and you want to break replication so that it doesn't replay
the DROP TABLE students that somebody ran on the master? It doesn't
have to be that WAL is unreadable or corrupt; it's enough for it to
contain changes you wish to avoid replaying.
> If you really don't care, just shutdown server, resetxlog and start
> her up - again, no need for new option.
To me, being able to say "pg_ctl promote_right_now -m yes_i_mean_it"
seems like a friendlier interface than making somebody shut down the
server, run pg_resetxlog, and start it up again.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
