From: | Markus Wagner <magnus(at)gmx(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: how to synchronize database operations? |
Date: | 2002-08-15 16:39:40 |
Message-ID: | 200208151839.40247.magnus@gmx.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-08-15 16:47:06 | Re: how to synchronize database operations? |
Previous Message | Linn Kubler | 2002-08-15 16:05:35 | Re: Problem with Now()? |