On Sun, Aug 9, 2020 at 1:21 AM Michael Paquier <michael@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-Fpzm1Oxuhw@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