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
> <dmi...@koterov.ru<javascript:_e({}, 'cvml', 'dmi...@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
>
>
