On Tue, Jan 11, 2011 at 8:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: >> On Tue, Jan 11, 2011 at 19:51, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> 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. 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. > >> I think it can be done cleaner in the tar file injection - I've been >> chatting with Heikki offlist about that. Not sure, but I have a >> feeling it does. > > One point that I'm particularly interested to see how you'll kluge it > is ensuring that the tarball contains only the desired temp data and not > also the "real" $PGDATA/backup_label, should there be a normal base > backup being done concurrently with the streamed one. > > The whole thing just seems too fragile and dangerous to be worth dealing > with given that actual usage will be a corner case. *I* sure wouldn't > trust it to work when the chips were down. >
Maybe if pg_start_backup() notices that there is another backup running should block waiting for another session to run pg_stop_backup() ? Or have a new function like pg_start_backup_wait() ? Considering that parallell base backups would be io-bound (or network-bound), there is little need to actually run them in parallell . Greetings Marcin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
