Michael Paquier <michael@paquier.xyz> 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