Home
The Toolkit for Online Communities
16685 Community Members, 0 members online, 2254 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : PG Woes

Forum OpenACS Q&A: PG Woes

Icon of envelope Request notifications

Collapse
Posted by Roberto Mello on
Hi all,

I am moving our database from an old server we had to the server
ArsDigita donated to our club a couple months ago.

I vacuumdb'd our database, dumped it, loaded postgres.sql in the new
machine and loaded the database. I don't know why but the whole thing
would be loaded, all the tables show up with d but no rows!

Look at the logs, correct one thing here and there, drop, create,
reload. After a couple dropdb/createdb I noticed that when I load the
dump file the output shows that all tables are already there, even if
I just dropped/created the whole database.

To test, I did dropdb and then createdb. This should give me a fresh
empty database, no matter what. When i got into psql and do a d,
voila, all my tables are still there. Any ideas?

The only "weird" thing I have in this installation of PG is that I
built it with Unicode support. Is that a problem?

Thanks.

Collapse
2: Response to PG Woes (response to 1)
Posted by Jonathan Ellis on
Don't know why this would happen, but I would try shutting down postgresql, then rm -rf the pgdata directory. :)
Collapse
3: Response to PG Woes (response to 1)
Posted by Don Baccus on
Do a dropdb and check PGDATA/database_name to see if the files are gone.  They should be.  Once they're gone, there's no way they can be there.  I know Unicode can be an issue with some things (and PG isn't the only piece of software to suffer such problems), but something this basic, hard to believe.

If the machine's up on a public IP I can play and take a look, if you'd like...

Collapse
4: Response to PG Woes (response to 1)
Posted by Roberto Mello on
Don, I don't know if PGDATA/database was there. Shouldn't it be deleted when you did a dropdb?

I noticed I didn't build PG with readline so that was the excuse I needed to rebuild it, this time without unicode.

Rebuilt it and it loaded right. I am not 100% sure the problem was with unicode but it went away. Thanks for the help tho.

Collapse
5: Response to PG Woes (response to 1)
Posted by Don Baccus on
I know that unicode's been a thorn in the side, there's a Japanese guy  who does most of the work trying to support it (big surprise that it's not one of us yanks, eh?).  You might want to spend some time reading the PG mailing list archives before diving into a fulltime unicode deployment...
Collapse
6: Response to PG Woes (response to 1)
Posted by Henry Minsky on
I'm up to my ears in Unicode development for AOLserver/ACS/Oracle. If you
have questions, particularly about Japanese, ask me. We have a couple of projects running in Japan which support Japanese charsets for
ACS 3.4.5 or later.

I've got a small patch to AOLserver 3.1 which makes it possible  to handle user input in non-ISO-8859-1 charsets. There are
some touchy areas related to when charset encoding conversion gets
performed on user-posted data , and how this interacts with the ACS request processor. I'm working on the i18n for ACS 4 now, so this stuff will work more cleanly in that framework.

I have no idea how Postgres deals with Unicode, but I can help debug
problems with AOLserver. Rob Mayoff wrote the main modifications to
AOLserver to allow it to perform encoding conversions when sending
pages, but there is some extra work that needs to be done in ACS to allow it to load tcl/html/adp files which are in non latin-1 encodings.

You can start by looking at http://imode.arsdigita.com/i18n for some
notes. That happens to be one of my development servers as well, so it may be
out of commission from time to time.