Re: [HACKERS] pg_dump inconsistences

Поиск
Список
Период
Сортировка
От Don Baccus
Тема Re: [HACKERS] pg_dump inconsistences
Дата
Msg-id 3.0.1.32.19990525220306.00dd26a8@mail.pacifier.com
обсуждение исходный текст
Ответ на pg_dump inconsistences  (Vadim Mikheev <vadim@krs.ru>)
Список 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 по дате отправления:

Предыдущее
От: Ari Halberstadt
Дата:
Сообщение: Re: [HACKERS] pg_dump core dump, upgrading from 6.5b1 to 5/24 snapshot
Следующее
От: Don Baccus
Дата:
Сообщение: Re: [HACKERS] pg_dump inconsistences