From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allowing multiple concurrent base backups |
Date: | 2011-01-14 13:05:05 |
Message-ID: | AANLkTinfEq89Y2j4+coMCYA1W156Sj6hkburSzg1v+Uu@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 13, 2011 at 22:32, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-14 13:20:34 | Re: Error code for "terminating connection due to conflict with recovery" |
Previous Message | Simon Riggs | 2011-01-14 12:54:43 | Re: Recovery control functions |