On Thu, Jan 10, 2019 at 04:52:53PM -0800, Andres Freund wrote: > It's a minor simplification for code that's existed for quite a > while. Not worth it.
Meh, I disagree for the ready_to_display part as it has been around for a long time: commit: 9ed551e0a4fdb046d8e5ea779adfd3e184d5dc0d author: Alvaro Herrera <alvhe...@alvh.no-ip.org> date: Wed, 29 Jun 2016 16:57:17 -0400 Add conninfo to pg_stat_wal_receiver I was honestly unhappy from the start with it because there was no actual way to have the WAL receiver *not* save the original connection string. In my opinion, getting rid of it is worth it because this really simplifies the way the WAL receiver data visibility is handled at SQL level and we don't finish by using again and again the same field for different purposes, consolidating the code. For the reloading part, we also make the WAL receiver rely on the GUC context and stop it if there is a change in primary_conninfo and primary_slot_name. It would be inconsistent to rely on the GUC context for one thing, and the startup process for the other one. Adding a safeguard to fail WAL receiver startup is actually more of sanity check that anything else (that could be an assertion but for forks a failure is of better benefit). At this stage, I would like to hear more opinions before doing or not doing something. Alvaro, you got involved in the introduction of ready_to_siplay. Peter, you have committed the merge of the recovery params. Perhaps you have an opinion to share? -- Michael
signature.asc
Description: PGP signature