On Friday 17 October 2008 11:55:19 Dan Armbrust wrote:
> It would seem that way. But if you have ever tried programming with
> the constraints of an InstallAnywhere installer, you would know why :)
>
if you are the only user, force a restart into single user mode, then drop the
database, and res
"Dan Armbrust" <[EMAIL PROTECTED]> writes:
> On windows, if I attempt to drop a database when I am purposefully
> holding a connection open to the DB, it fails immediately - ~ 100 ms.
> On linux, if I do the same thing, the drop database command takes
> upwards of 4 seconds before it gives up, and
This is interesting.
On windows, if I attempt to drop a database when I am purposefully
holding a connection open to the DB, it fails immediately - ~ 100 ms.
On linux, if I do the same thing, the drop database command takes
upwards of 4 seconds before it gives up, and says it can't drop the
DB.
On Fri, Oct 17, 2008 at 9:16 AM, Dan Armbrust
<[EMAIL PROTECTED]> wrote:
> I don't suppose that there is any easy way way that I can stop and/or
> disable the Autovac temporarily for the database that I want to drop.
>
> The only thing that I have seen so far, is that I would have to add
> rows to
It would seem that way. But if you have ever tried programming with
the constraints of an InstallAnywhere installer, you would know why :)
On Fri, Oct 17, 2008 at 10:43 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Dan Armbrust escribió:
>> I don't suppose that there is any easy way way that
Dan Armbrust escribió:
> I don't suppose that there is any easy way way that I can stop and/or
> disable the Autovac temporarily for the database that I want to drop.
>
> The only thing that I have seen so far, is that I would have to add
> rows to the pg_autovacuum table for each table in my dat
I don't suppose that there is any easy way way that I can stop and/or
disable the Autovac temporarily for the database that I want to drop.
The only thing that I have seen so far, is that I would have to add
rows to the pg_autovacuum table for each table in my database, but
I'mnot confident t
Dan Armbrust escribió:
> Do I really just have to keep trying the DROP command N times in a
> row, until it decides it wants to work? That really doesn't seem
> right.
Yes. Most of the time it'll work on the first try, but if you add the
retry loop your operation is guaranteed to work all the t
On Fri, Oct 17, 2008 at 8:28 AM, Dan Armbrust
<[EMAIL PROTECTED]> wrote:
> But there is no user2. I _know_ I am the only user of this database.
>
> So how can User 1 create a race condition by himself?
>
> Or is this something PostgreSQL is doing internally (like vacuum) ?
>
> Do I really just hav
But there is no user2. I _know_ I am the only user of this database.
So how can User 1 create a race condition by himself?
Or is this something PostgreSQL is doing internally (like vacuum) ?
Do I really just have to keep trying the DROP command N times in a
row, until it decides it wants to wor
On Fri, Oct 17, 2008 at 8:11 AM, Dan Armbrust
<[EMAIL PROTECTED]> wrote:
>> There are obvious race conditions in that assumption. Why don't you
>> just try the drop and see if it succeeds?
>>
>>regards, tom lane
>>
>
> I don't follow - why is there a race condition? I'm dr
> There are obvious race conditions in that assumption. Why don't you
> just try the drop and see if it succeeds?
>
>regards, tom lane
>
I don't follow - why is there a race condition? I'm driving the
commands into postgresql via the command line.
The command that does t
"Dan Armbrust" <[EMAIL PROTECTED]> writes:
> First, after validating some passwords, my installer will run this command:
> psql -c "select datname from pg_stat_activity where datname='fred'" -U
> username -d template1
> I then scan the output looking for 'fred'. My (perhaps incorrect)
> assumptio
13 matches
Mail list logo
