Re: pg_start_backup does not actually allow for consistent, file-level backup

Поиск
Список
Период
Сортировка
От otheus uibk
Тема Re: pg_start_backup does not actually allow for consistent, file-level backup
Дата
Msg-id CALbQNd0gQnx1EEyJhXupnFFZ-AS5zbA3j_j_V1UDpT6cWwUiCw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_start_backup does not actually allow for consistent, file-level backup  (otheus uibk <otheus.uibk@gmail.com>)
Ответы Re: pg_start_backup does not actually allow for consistent, file-level backup  (Adrian Klaver <adrian.klaver@aklaver.com>)
Re: pg_start_backup does not actually allow for consistent, file-level backup  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: pg_start_backup does not actually allow for consistent, file-level backup  (Albe Laurenz <laurenz.albe@wien.gv.at>)
Список pgsql-general
Дерево обсуждения
On Mon, Jun 8, 2015 at 3:13 PM, otheus uibk <otheus.uibk@gmail.com> wrote:
Thank you, all.  The manual for 9.4 is indeed clearer on this point than the 9.1 version.  

Just to nit-pick, I see nowhere in either version of the manual the indication that it is normal for postgresql to continue to update files in its data catalog between pg_start_backup and pg_stop_backup. The closest I see comes in this paragraph:

** Some file system backup tools emit warnings or errors if the files they are trying to copy change while the copy proceeds. When taking a base backup of an active database, this situation is normal and not an error.

Does "this situation" refer to the tools emitting warnings or to the fact that postgresql is updating the files? It might be the case, for instance, that timestamps are updated but not the contents of the files (this is what I had assumed prior to today).

--

В списке pgsql-general по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: pg_start_backup does not actually allow for consistent, file-level backup