Re: Race condition with libpq

Thanks Tom,

> You're missing the point.  It's the DROP that's failing, not the CREATE,
> and it's failing because the old backend is still connected to the
> victim database.

Actually, I understand that it's the DROP that's failing. What I didn't
understand is that connection closure was asynchronous, but everything else
is synchronous.

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.

> [template1] is not used for any "internal" operations.  It is
> conventionally present so that clients have a standard place to
> connect to.

Perhaps I'm misunderstanding the manual - "4.1: When a new database is
created, the template database [template1] is essentially cloned. This means
that any changes you make in template1 are propagated to all subsequently
created databases."

Thanks again for your quick response,
Dietmar