| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fast promotion not used when doing a recovery_target PITR restore? |
| Date: | 2017-06-27 21:04:23 |
| Message-ID: | CAB7nPqTAQZ0SNbukD3h_kizCVaK9Tg=qAFrMDFPM=4K3A12iCw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 28, 2017 at 3:44 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> I'm far from convinced by this. By now WAL replay with checkpointer,
> bgwriter, etc. active is actually *more* tested than the cases without
> it. The likelihood of bugs is higher in the less frequently exercised
> paths, and given that replication exercises the situation with all those
> processes active on a continuous basis, I'm fairly unconvinced by your
> argument.
Crash recovery is the last thing where failures should never happen.
Don't you think that it should remain simple as it has been designed
originally? It seems to me that the argument for keeping things simple
has higher priority than performance in being able to reconnect by
delaying the checkpoint.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-06-27 21:13:28 | Re: Fast promotion not used when doing a recovery_target PITR restore? |
| Previous Message | Tom Lane | 2017-06-27 20:26:15 | Re: Reducing pg_ctl's reaction time |