Re: Incomplete description of pg_start_backup? - Mailing list pgsql-hackers

From Dmitry Koterov
Subject Re: Incomplete description of pg_start_backup?
Date
Msg-id CA+CZih5sUKot+WnS3SjU=ae_5_P8YAQkRAbs8Za8VKKf8BLbHg@mail.gmail.com
Whole thread Raw
In response to Re: Incomplete description of pg_start_backup?  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Incomplete description of pg_start_backup?  (Jeff Janes <jeff.janes@gmail.com>)
List 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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: local_preload_libraries logspam
Next
From: Robins Tharakan
Date:
Subject: Add more regression tests for ASYNC