Re: pg_start_backup - backups - Mailing list pgsql-admin

From Kevin Grittner
Subject Re: pg_start_backup - backups
Date
Msg-id 4DA2DC30020000250003C644@gw.wicourts.gov
Whole thread Raw
In response to Re: pg_start_backup - backups  ("David Roland" <david.roland@soapware.com>)
List pgsql-admin
"David Roland" <david.roland@soapware.com> wrote:

> changes to the data folder continue even after the PG_START_BACKUP
> command has been issued. This implies to me that the contents of
> any copy of the data folder may be unreliable. i.e. the copy may
> not reflect the state of the data folder either before the copy
> started or after the copy has finished. It may reflect the state
> of the data folder in some transient form.

Right.

> Assuming this is true, is the copy still usable for restoration?

Yes.

> If so, how does PostgreSQL get the data folder to a stable
> state? Is it by the use of the WAL files that may be created
> during the backup process and the restore.config file?

Exactly.  Simplifying somewhat:

- The pg_start_backup causes the WAL position to be remembered.  You
  will need to start WAL replay at this point.

- Every significant change to a page is WAL-logged.

- Changes after you record the restart point may or may not be in
  the base backup.

- After the base backup copying is complete, pg_stop_backup records
  the WAL position.  You will need to replay WAL *at least* to this
  point to have a consistent database.

- WAL replay will bring every page modified after the "start" to a
  valid state, whether or not any or all direct modifications to
  that page made it into the base backup.

- This actually goes beyond page fix-ups to file creation and
  deletion, etc.

-Kevin

pgsql-admin by date:

Previous
From: "French, Martin"
Date:
Subject: Re: Out Of Memory 8.1
Next
From: Jerry Sievers
Date:
Subject: Re: unsupported header version error