Hi Tom,
I believe that you are right. But to keep my things simple, I would like to
not extend my application specific database interface, which knows create and
delete, with a new function, which could be called "recreate", just to face
this synchronization problem. Of course, I would do that, if no other
solution exists. But I am thinking of the following: What about making my
application specific functions create/delete more robust, by adding the
following (pseudo-) code to each of them?
...
PQfinish();
while (postmaster_still_active())
think_about_beautiful_things();
...
Well, the only thing I need to get happy would be the implementation of
postmaster_still_active (for think_about_beautiful_things i already have a
great idea!).
Greetings,
Markus
> My guess is that you are closing the connection to the backend that did
> the DROP and opening a new one for the CREATE. The trouble with this is
> that it takes a few milliseconds for the old backend to clean up and go
> away. It's quite possible for the new backend to see the old one as
> still active, and since it doesn't know what the other one might be
> doing to template1, it disallows the CREATE.
>
> If you issue the DROP and the CREATE in the same backend process,
> I suspect your problem will go away.
