On Sun, Aug 9, 2020 at 1:21 AM Michael Paquier <mich...@paquier.xyz> wrote: > Sorry for the late reply. I have been looking at that stuff again, > and restore_command can be called in the context of a WAL sender > process within the page_read callback of logical decoding via > XLogReadDetermineTimeline(), as readTimeLineHistory() could look for a > timeline history file. So restore_command is not used only in the > startup process.
Hmm, interesting. But, does that make this change wrong, apart from the comments? Like, in the case of primary_conninfo, maybe some confusion could result if the startup process decided whether to ask for a WAL receiver based on thinking primary_conninfo being set, while that process thought that it wasn't actually set after all, as previously discussed in http://postgr.es/m/ca+tgmozvmjx1+qtww2tsnphrnkwkzxc3zsrynfb-fpzm1ox...@mail.gmail.com ... but what's the corresponding hazard here, exactly? It doesn't seem that there's any way in which the decision one process makes affects the decision the other process makes. There's still a race condition: it's possible for a walsender to use the old restore_command after the startup process had already used the new one, or the other way around. However, it doesn't seem like that should confuse anything inside the server, and therefore I'm not sure we need to code around it. If you or someone else thinks we do, then it'd be nice to hear why, and what guarantees you think we should be aiming to achieve. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company