Re: [HACKERS] pg_dump inconsistences - Mailing list pgsql-hackers

From Don Baccus
Subject Re: [HACKERS] pg_dump inconsistences
Date
Msg-id 3.0.1.32.19990525220306.00dd26a8@mail.pacifier.com
Whole thread Raw
In response to pg_dump inconsistences  (Vadim Mikheev <vadim@krs.ru>)
List pgsql-hackers
At 12:09 PM 5/26/99 +0800, Vadim Mikheev wrote:
>To return consistent results pg_dump should run all queries
>in single transaction, in serializable mode. It's old problem.
>But now when selects don't block writers we are able to do this.

>Comments/objections?

This would remove one of the major barriers to deployment of
Postgres in serious, heavy-traffic environments, particularly
the Web, where no clock boundaries are respected for globally
interesting sites.

The use of db's to back web sites is the most intriguing aspect
of modern db development, IMO.  Why else would an old compiler
like me have an interest? :)

And Postgres has problems in this regard, one of which you
point out in this post.

Let me hasten to add that the development direction of the
db is congruent with the needs of web site users like myself.
The removal of table-level locking, for instance.  Removing
of fsync after select-only queries would help a lot, too,
after experimentation verified by a comment to the effect
that postgres does this (from a future enhancements list) I
sped my site a lot by including selects in begin/end transactions.
YUK.

On and on.   Anyway, y'all are moving in the right direction(s)
and at a good pace, too.  Why not do things such as you 
describe, when doing so better places your product in the
mix for continuous use ala the Web?



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


pgsql-hackers by date:

Previous
From: Ari Halberstadt
Date:
Subject: Re: [HACKERS] pg_dump core dump, upgrading from 6.5b1 to 5/24 snapshot
Next
From: Don Baccus
Date:
Subject: Re: [HACKERS] pg_dump inconsistences