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> (raw)
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: dcmay@dmis.com, tgl@sss.pgh.pa.us
Subject: Re: Race condition with libpq
In-Reply-To: <00a001c323a6$cbb02d90$fb02a8c0@muskrat>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox