On Tue, May 31, 2016 at 10:06 AM, Thalis Kalfigkopoulos
wrote:
> @DavidJohnston, I don't know why, but yes, I am doing all operations
> connected from template1.
>
>>
>> Oddly, the notes on the aforementioned page state: "The principal
>> limitation is that no other sessions can be connected to t
Hi all.
Ok, Igor nailed it. That was lame on my behalf. I apparently "contaminated"
my template1 db at some point (restored into it instead of into the target
"dafodb"). A simple \d confirmed this immediately.
Apologies for the false alarm.
@DavidJohnston, I don't know why, but yes, I am doing a
On Tue, May 31, 2016 at 9:49 AM, Thalis Kalfigkopoulos
wrote:
> Intention: to drop a database and recreate it.
> Expectation: the newly created db should be empty
> What happens: dropping is fast, creation is slow, and when I reconnect,
> all the data objects are still there.
>
[...]
Even wei
Hi Thalis
On Tue, May 31, 2016 at 3:49 PM, Thalis Kalfigkopoulos
wrote:
> Intention: to drop a database and recreate it.
> Expectation: the newly created db should be empty
> What happens: dropping is fast, creation is slow, and when I reconnect,
> all the data objects are still there.
>
> Comma
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Thalis Kalfigkopoulos
Sent: Tuesday, May 31, 2016 9:49 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Drop/Re-Creating database extremely slow + doesn't lose data
Intention: to d
Intention: to drop a database and recreate it.
Expectation: the newly created db should be empty
What happens: dropping is fast, creation is slow, and when I reconnect, all
the data objects are still there.
Commands (tried both through command line with dropdb/createdb and through
psql)
pgdba@tem
