Michael Paquier <michael@xxxxxxxxxxx> writes: > On Thu, Mar 22, 2018 at 06:55:12PM -0400, Tom Lane wrote: >> Anyway, it's clearly not very nice that postgres_fdw makes no attempt >> to do a graceful shutdown of its remote connection. I don't know that >> this rises to the level of a bug, exactly, but if somebody wanted to >> send in a patch it'd probably get accepted. > I won't qualify that as a bug, this is mainly noise. Still I agree that > it would be cleaner to make more efforts in finishing the connections > when the session goes down. You would roughly just need to register an > on_shmem_exit callback which loops through all the connections to finish > them. That was my basic thought. Not sure whether on_proc_exit is better than on_shmem_exit, but one or the other. > Now would we want to slow down the session shutdown just for > that? I am less sure particularly if there is lag between the remote > and the local servers. Yeah, I think the sticky part might be what to do if the shutdown attempt blocks. I vaguely recall that PQfinish just fires off an 'X' protocol message and doesn't wait for an answer, so maybe there's not huge risk there, but you don't really want to risk any delay. (The worst-case scenario is that you've gotten SIGTERM from init because a system shutdown is beginning, and you don't have much time before it brings the hammer down with SIGKILL, preventing a clean database shutdown and thereby risking data corruption if anything is wrong with the filesystem sync semantics. I am not sure if it's more or less dangerous for this purpose if the "remote" session is another backend in the same cluster, and therefore also subject to the same shutdown signal.) regards, tom lane
