[BUGS]
i am trying to get some help around this, i couldnt find anywhere not on cygwin.com or anywhere else and i also saw that many others have the same problem on forums but no replies. please help : thanks in advance creating configuration files... ok creating template1 database in /usr/local/pgsql/data2/base/1... Signal 12 initdb: failed initdb: removing data directory "/usr/local/pgsql/data2" ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] drop + create database restores previous tables and data
I just installed Postgres v 8.0.3. I loaded by databases, then decided to reload a database. I dropped the database with dropdb (I also tried DROP DATABASE in pgsql), then I recreated the database with createdb. When I tried to reload the data from the database dump, I got errors because the relations and data were already in the newly created database. I've since tried dropping and recreating several times. After dropping and creating, I can connect to the database and see all of the data that was there before dropping the database; without reloading anything. At this early stage, I can remove everything and recreate the entire installation from scratch, but this will create a real problem in the future. Douglas Toltzman, Oak Street Software, Inc. voice: 910-526-5938 http://www.oakstreetsoftware.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] drop + create database restores previous tables and data
Maybe you restored to template1 by mistake? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Douglas Toltzman > Sent: Monday, May 23, 2005 4:38 AM > To: pgsql-bugs@postgresql.org > Subject: [BUGS] drop + create database restores previous > tables and data > > I just installed Postgres v 8.0.3. I loaded by databases, > then decided to reload a database. I dropped the database > with dropdb (I also tried DROP DATABASE in pgsql), then I > recreated the database with createdb. > When I tried to reload the data from the database dump, I got > errors because the relations and data were already in the > newly created database. I've since tried dropping and > recreating several times. > After dropping and creating, I can connect to the database > and see all of the data that was there before dropping the > database; without reloading anything. > > At this early stage, I can remove everything and recreate the > entire installation from scratch, but this will create a real > problem in the future. > > Douglas Toltzman, Oak Street Software, Inc. > voice: 910-526-5938 > http://www.oakstreetsoftware.com/ > > > ---(end of > broadcast)--- > TIP 8: explain analyze is your friend > > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] BUGS
On 5/21/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > i am trying to get some help around this, i couldnt find anywhere not on > cygwin.com or anywhere else and i also saw that many others have the same > problem on forums but no replies. please help : > thanks in advance > > > creating configuration files... ok > creating template1 database in /usr/local/pgsql/data2/base/1... Signal 12 > > initdb: failed > initdb: removing data directory "/usr/local/pgsql/data2" > Maybe you wanna check the http://archives.postgresql.org and even subscribe to pgsql-cygwin list. This message could help you, i think http://archives.postgresql.org/pgsql-cygwin/2004-06/msg00074.php -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] pg_dump table ordering bug [8.0.1]
On Thu, 2005-03-24 at 17:27 -0500, Tom Lane wrote: > Andreas Lange <[EMAIL PROTECTED]> writes: > > Our upgrade from 7.4.6 to 8.0.1 only had one small glitch. Two tables > > got dumped in the wrong order (before their dependecies) and had to get > > their contents added manually after the restore. I've atleast isolated > > the part where things go wrong. > > I don't think this is a pg_dump bug: the problem is you are abusing > check constraints to emulate foreign key constraints. pg_dump has no > way to know what those functions are doing and therefore no way to > realize that the check constraints impose a data load ordering > dependency. Furthermore, the check constraints are fundamentally wrong > anyway because they don't create a two-way relationship --- that is, > altering the referenced tables won't raise an error if the check is now > violated for something in the referencing table. (Sorry for the long delay here!) Could this be resolved simply by having pg_dump write out all constraint statements after all insert and trigger statements? Then no data-order-dependent constraints will be triggered when the dump is loaded, and even constraints that aren't met when when the dump is taken won't be triggered when the data is re-loaded. (I would say that would be a feature not a bug, since as I understand it the point of pg_dump is to replicate a db setup, with it also being a separate sanity checker merely a possible benefit. And in any event, if a few "special" rows don't meet constraints, having had to have been entered before the constraints were put into place, those rows could still be restored without problems. Whether that's indicative of poor schema design is a separate issue.) Are there any downsides to changing the order of pg_dump output with respect to constraints? (Versus requiring users to alter their schema design.) -- Mark Shewmaker [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
