| From: | Asim Rama Praveen <apraveen(at)pivotal(dot)io> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Cc: | Konstantin Knizhnik <knizhnik(at)garret(dot)ru> |
| Subject: | Re: Replication & recovery_min_apply_delay |
| Date: | 2020-01-27 11:40:55 |
| Message-ID: | 158012525598.742.4628546558494254315.pgcf@coridan.postgresql.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation: not tested
The logic to start WAL receiver early should not be coupled with recovery_min_apply_delay GUC. WAL receiver's delayed start affects replication in general, even when the GUC is not set.
A better fix would be to start WAL receiver in the main replay loop, as soon as consistent state has been reached.
As noted during previous reviews, scanning all WAL just to determine streaming start point seems slow. A faster solution seems desirable.
The new status of this patch is: Waiting on Author
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Asim R P | 2020-01-27 11:45:45 | Re: Replication & recovery_min_apply_delay |
| Previous Message | Peter Eisentraut | 2020-01-27 11:16:02 | Re: pause recovery if pitr target not reached |