Re: pg_dump locking info
От | Thom Brown |
---|---|
Тема | Re: pg_dump locking info |
Дата | |
Msg-id | AANLkTikoALbeega4O1s70u_5x62Ku2P9txCo+o7-fMRR@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dump locking info (Thom Brown <thom@linux.com>) |
Ответы |
Re: pg_dump locking info
Re: pg_dump locking info |
Список | pgsql-docs |
On 15 August 2010 10:29, Thom Brown <thom@linux.com> wrote: > On 15 August 2010 10:01, Thom Brown <thom@linux.com> wrote: >> Is this right? I'm looking at >> http://www.postgresql.org/docs/current/static/backup-dump.html >> >> It says, "pg_dump does not block other operations on the database >> while it is working. (Exceptions are those operations that need to >> operate with an exclusive lock, such as most forms of ALTER TABLE.)" >> >> So pg_dump actually performs an ALTER TABLE sometimes? :S >> > > And whilst I was perusing the docs, I also noticed this on > http://www.postgresql.org/docs/current/static/backup.html > > "Each has its own strengths and weaknesses. Each is discussed in turn below." > > That sentence is at the bottom of the page. It would make sense in a > PDF, but might be a confusing in section-by-section HTML > documentation. > Another thing I noticed, going back to http://www.postgresql.org/docs/current/static/backup-file.html , is that it makes no mention of the fact that file system level backups are useless if being used to restore in a different major version. Maybe "There are two restrictions, however, which make this method impractical, or at least inferior to the pg_dump method" should be changed to "There are three..." and add the point that pg_dump/pg_dumpall is mostly immune to such limitations. -- Thom Brown Registered Linux user: #516935
В списке pgsql-docs по дате отправления: