On 3 September 2010 16:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> On 03/09/10 15:16, Greg Stark wrote:
>>> On Fri, Sep 3, 2010 at 12:19 PM, Heikki Linnakangas
>>> <heikki.linnakangas@enterprisedb.com> wrote:
>>>> * 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.
>>>
>>> Well there's no particular reason we couldn't support having multiple
>>> pg_start_backup() pending either. It's just not usually something
>>> people have need so far.
>
>> The backup label file makes that hard. There can be only one at a time.
>
> I don't actually see a use-case for streaming multiple concurrent
> backups. How many people are going to be able to afford that kind of
> load on the master's I/O bandwidth?
To make it affordable, could functionality be added to allow slaves to
become chainable? (i.e. master streams to standby 1, which streams to
standby 2 etc) This would help reduce bandwidth for normal streaming
replication too, which would be useful on particularly busy databases.
Obviously in synchronous replication this would be horribly slow so
not feasible for that.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
