Re: [HACKERS] pg_dump inconsistences

At 12:57 AM 5/26/99 -0400, Bruce Momjian wrote:

>> As far as I see each COPY table TO STDOUT is executed in
>> its own transaction. This may cause referential inconsistences
>> (pg_dump saves foreign keys, then other transaction deletes some
>> foreign and primary keys and commits, now pg_dump saves
>> primary keys and loses some of them, breaking referential
>> integrity).

>Oh, I get it.

For some reason, I always thought this was a "feature", which is
why Vadim's suggestion to fix it seems ... obvious?

This gives a consistent snapshot ability, right? Currently,
one must shut down access to the db in order to ensure referential
consistencies, a pain on a 24/7 web site, admittedly a relatively
new application.

Oracle, last I heard, wants about $9,000 for deployment on a
web platform (despite the lower price of $1,350 for a five
user license). This is a major reason I'm here. Sybase is
free at the moment, but has performance problems with the
particular web server I'm using (AOLServer), weird because
that server's so efficient with other dbs like Oracle and
Postgres (the interface 'tween web server and db is different,
that's why, Sybase is a good performing db on its own).

Postgres could be a major factor in this world IF it can
get past its flakey reputation. The recent large memory
leak bug fix is a step in the right direction, a large one.
So is the notion of a consistent dump by pg_dump.

- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, and other goodies at
http://donb.photo.net