Re: Incomplete description of pg_start_backup?

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Incomplete description of pg_start_backup?
Дата
Msg-id CAMkU=1wpAzLGPfHQkk5FgmK=_0Jbjcik7yj11h+GeE5mau1efA@mail.gmail.com
обсуждение исходный текст
Ответ на Incomplete description of pg_start_backup?  (Dmitry Koterov <dmitry@koterov.ru>)
Ответы Re: Incomplete description of pg_start_backup?
Список pgsql-hackers
On Tue, Apr 30, 2013 at 3:24 PM, Dmitry Koterov <dmitry@koterov.ru> wrote:
I think that at http://www.postgresql.org/docs/current/static/functions-admin.html and http://www.postgresql.org/docs/current/static/continuous-archiving.html two important points on how pg_start_backup() works are missing:

1. After pg_start_backup() and till pg_stop_backup() VACUUM is denied (e.g. autovacuum is turned off), so the new data is always appended to data files, is never written at their middle.

This is not the case.  Autovacuum continues to run during the backup.

 
This allows to archive the data directory using any copying tools (rsync, tar, cp etc.). If you forget to call pg_stop_backup() by accident, data files will grow forever. So pg_start_backup() switches the database to "append-only mode" which is safe to backup without stopping (data files temporarily become append-only, WAL logs are append-only always).

No, it doesn't work that way.  I don't know why appending would be any safer than normal updates would be anyway.  WAL replay fixes up any problems that might arise.


2. After pg_start_backup() and till pg_stop_backup() full_page_writes is forced to be ON.

Effectively yes, this is documented in one of your links above (and is one of the reasons vacuuming during the backup is not a problem)

Cheers,

Jeff

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

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: Substituting Checksum Algorithm (was: Enabling Checksums)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Substituting Checksum Algorithm (was: Enabling Checksums)