On 2017-06-26 13:42:52 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-06-26 12:32:00 -0400, Tom Lane wrote: > >> ... But I wonder whether it's intentional that the old > >> walreceiver dies in the first place. That FATAL exit looks suspiciously > >> like it wasn't originally-designed-in behavior. > > > It's quite intentional afaik - I've complained about the bad error > > message recently (we really shouldn't say "no COPY in progress), but > > exiting seems quite reasonable. Otherwise we'd have add a separate > > retry logic into the walsender, that reconnects without a new walsender > > being started. > > Ah, I see. I'd misinterpreted the purpose of the infinite loop in > WalReceiverMain() --- now I see that's for receiving requests from the > startup proc for different parts of the WAL stream, not for reconnecting > to the master.
Right. And if the connection fails, we intentionally (whether that's good or bad is another question) switch to restore_command (or pg_xlog...) based recovery, in which case we certainly do not want the walsender around. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
