On 11.01.2011 20:51, Tom Lane wrote:
Heikki Linnakangas<heikki.linnakan...@enterprisedb.com> writes:
I implemented this in two ways, and can't decide which I like better:
1. The contents of the backup label file are returned to the caller of
do_pg_start_backup() as a palloc'd string.
2. do_pg_start_backup() creates a temporary file that the backup label
is written to (instead of "backup_label").
Implementation 1 changes more code, as pg_start/stop_backup() need to be
changed to write/read from memory instead of file, but the result isn't
any more complicated. Nevertheless, I somehow feel more comfortable with 2.
Seems like either one of these is fairly problematic in that you have to
have some monstrous kluge to get the backup_label file to appear with
the right name in the tarfile.
Oh. I'm surprised you feel that way - that part didn't feel ugly or
kludgey at all to me.
How badly do we actually need this?
I don't think the use-case for concurrent base backups is all that large
in practice given the I/O hit it's going to involve.
It makes it very convenient to set up standbys, without having to worry
that you'll conflict e.g with a nightly backup. I don't imagine people
will use streaming base backups for very large databases anyway.
--
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
