On 03/09/10 14:25, Thom Brown wrote:
On 3 September 2010 12:19, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
TODO:
* We need a smarter way to do pg_start/stop_backup() with this. At the
moment, you can only have one backup running at a time, but we shouldn't
have that limitation with this built-in mechanism.
Would it be possible to not require pg_start/stop_backup() for this
new feature? (yes, I'm probably missing something obvious here)
Well, pg_start_backup() does several things:
1. It sets the forceFullPageWrites flag, so that we don't get partial
pages in the restored database.
2. It performs a checkpoint
3. It creates a backup label file
We certainly need 1 and 2. We don't necessary need to write the backup
label file to the data directory when we're streaming the backup
directly to the client, we can just include it in the streamed archive.
pg_stop_backup() also does several things:
1. It clears the forceFullPageWrites flag.
2. It writes an end-of-backup WAL record
3. It switches to new WAL segment, to get the final WAL segment archived.
4. It writes a backup history file
5. It removes the backup label file.
6. It waits for all the required WAL files to be archived.
We need 1, but the rest we could do in a smarter way. When we have more
control of the backup process, I don't think we need the end-of-backup
WAL record or the backup label anymore. We can add the pg_control file
as the last file in the archive, and set minRecoveryPoint in it to the
last WAL record needed to recover.
So no, we don't really need pg_start/stop_backup() per se, but we'll
need something similar...
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
