On Tue, Dec 11, 2018 at 09:34:58PM -0800, Andres Freund wrote: > I am not convinced this is a good idea. This allows the state of > walrcv and startup to diverge, they could e.g. have different > configuration, due to differently time config reloads. And they need > to communicate via shmem anyway, so there's not a lot of complexity > avoided. And I think it's good to be able to show the active > connection via functions, rather than the one currently in pg.conf, > which might be different.
Well, the conninfo and slot name accessible to the user are the values available only once the information of the WAL receiver in shared memory is ready to be displayed. Relying more on the GUC context has the advantage to never have in shared memory the original string and only store the clobbered one, which actually simplifies what's stored in shared memory because you can entirely remove ready_to_display (I forgot to remove that in the patch actually). If those parameters become reloadable, you actually rely only on what the param context has, and not on what the shared memory context may have or not. Removing entirely ready_to_display is quite appealing actually.. -- Michael
signature.asc
Description: PGP signature
