At 13:08 16/07/2002 -0700, Josh Berkus wrote:
>I'd like to work with someone on pinpointing the problem, as obviously this
>could be a critical issue for production databases. However, I'm not sure
>how to submit the files as they are very large (> 90mb) and how can I send
>the original database not as a backup file?
If Tom's not already on top of this, I'd be happy to help. There seem to be
a few possibilities:
1. The pg_* tables have bad data in them, causing pg_dump to fail and not
report the failure.
2. The pg_* tables are fine, and pg_dump has a serious problem.
3. The data being dumped is somehow relevant.
We can remove (3) by just doing a schema-only dump of the original DB. If
this works, we know it's data related. Ugh.
Most likely it's (1), and someone will need to do as Tom suggested, and run
through pg_dump on the database in question. Assuming you have a vanilla PG
install, shutting down the database and copying the files *may* work. I am
happy to ftp the files if you are comfortable with that, although debugging
on-site would be easier.
Did you see any warning or error messages during the dump or restore?
Are you dumping to a script, tar file, or custom backup file? If either of
the last two, does 'pg_restore -l' on the backup file show the lost view?
When you dump the database (using '-v'), do you see the view in the output?
>--
>-Josh Berkus
> Aglio Database Solutions
> San Francisco
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Don't 'kill -9' the postmaster
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
