Re: Race condition with libpq - Mailing list pgsql-interfaces

From Dietmar May
Subject Re: Race condition with libpq
Date
Msg-id 00a001c323a6$cbb02d90$fb02a8c0@muskrat
Whole thread Raw
In response to Re: Race condition with libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-interfaces
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



pgsql-interfaces by date:

Previous
From: "Dietmar May"
Date:
Subject: Re: Race condition with libpq
Next
From: "Dietmar May"
Date:
Subject: Re: Race condition with libpq