|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||pgsql-hackers(at)lists(dot)postgresql(dot)org, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, simon(at)2ndquadrant(dot)com, ams(at)2ndquadrant(dot)com, sk(at)zsrv(dot)org, masao(dot)fujii(at)gmail(dot)com|
|Subject:||Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Wed, Dec 12, 2018 at 02:55:17PM +0900, Michael Paquier wrote:
> 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..
I have been looking at that stuff this morning, and indeed
ready_for_display can be entirely removed. I think that's quite an
advantage as WalRcv->conninfo only stores the connection string
cloberred to hide security-sensitive fields and it never has to save the
initial state which could have sensitive data, simplifying how the WAL
receiver data is filled. I am adding that to the next commit fest.
|Next Message||Alexander Korotkov||2018-12-13 04:28:30||Re: gist microvacuum doesn't appear to care about hot standby?|
|Previous Message||Hao Wu||2018-12-13 03:02:34||Where to save data used by extension ?|