From: "Dietmar May" <dcmay@dmis.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-interfaces@postgresql.org>
Subject: Re: Race condition with libpq 
Date: Mon, 26 May 2003 12:49:38 -0400
Message-ID: <00a001c323a6$cbb02d90$fb02a8c0@muskrat>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <2072.1053966616@sss.pgh.pa.us>

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