Re: Race condition with libpq

Hi Tom,

> > So, why can't the server-side code that closes the connection
> > release any resources associated with that connection before
> > the socket is closed? It seems that doing so could fix this
> > problem quite cleanly.
>
> How would that help? The client isn't waiting around for it,
> because it already closed its socket.

Ah-ha! Your comments are really helping to narrow down the problem. Maybe
we're getting to a solution here.

Perhaps instead of simply shutting down the connection, PQfinish() could
request the server to close the connection, and block until the connection
is closed. The server would first clean up any resources associated with the
connection, and then close the connection. The client code would then be
sure that it no longer has any resources in use when the socket shuts down.

This would take care of the race condition, not only for the case of DROP
DATABASE, but perhaps for other cases as well. After all, there is really no
guaranteed order of process execution, nor of process execution scheduling,
nor of the priority at which various processes are running.

In theory, a whole host of other similar race condition failures could occur
due to the current design of connection closure. By changing this operation
slightly, the possibility of these race conditions can be eliminated.

The current behavior could perhaps still be supported using an extra boolean
parameter to PQfinish(), in case someone doesn't need to ensure that
server-side resources are released before returning from PQfinish().

Regards,
Dietmar