Re: Incomplete description of pg_start_backup?

Поиск
Список
Период
Сортировка
От Dmitry Koterov
Тема Re: Incomplete description of pg_start_backup?
Дата
Msg-id CA+CZih5sUKot+WnS3SjU=ae_5_P8YAQkRAbs8Za8VKKf8BLbHg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Incomplete description of pg_start_backup?  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: Incomplete description of pg_start_backup?
Список pgsql-hackers
Дерево обсуждения
Could you please provide a bit more detailed explanation on how it works? 

And how could postgres write at the middle of archiving files during an active pg_start_backup? if it could, here might be a case when a part of archived data file contains an overridden information "from the future", while wal files contain only information like "i want to write X to Z", not "i've overridden the following X with Y at the Z position". The appending is much better here, because unexpected appended data "from the future" may just be ignored.

On Wednesday, May 1, 2013, Jeff Janes wrote:
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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: local_preload_libraries logspam
Следующее
От: Robins Tharakan
Дата:
Сообщение: Add more regression tests for ASYNC