On Thu, Jan 13, 2011 at 22:32, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 13.01.2011 22:57, Josh Berkus wrote: >> >> On 1/13/11 12:11 PM, Robert Haas wrote: >>> >>> That's going to depend on the situation. If the database fits in >>> memory, then it's just going to work. If it fits on disk, it's less >>> obvious whether it'll be good or bad, but an arbitrary limitation here >>> doesn't serve us well. >> >> FWIW, if we had this feature right now in 9.0 we (PGX) would be using >> it. We run into the case of DB in memory, multiple slaves fairly often >> these days. > > Anyway, here's an updated patch with all the known issues fixed.
It's kind of crude that do_pg_stop_backup() has to parse the backuplabel with sscanf() when it's coming from a non-exclusive backup - we could pass the location as a parameter instead, to make it cleaner. There might be a point to it being the same in both codepaths, but I'm not sure it's that important... Doesn't this code put the backup label in *every* tarfile, and not just the main one? From what I can tell the code in SendBackupDirectory() relies on labelfile being NULL in tar files for "other tablespaces", but the caller never sets this. Finally, I'd move the addition of the labelfile to it's own function, but that's just me ;) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
