On 18.03.2011 13:56, Heikki Linnakangas wrote:
On 18.03.2011 10:48, Heikki Linnakangas wrote:
On 17.03.2011 21:39, Robert Haas wrote:
On Mon, Jan 31, 2011 at 10:45 PM, Fujii Masao
wrote:
On Tue, Feb 1, 2011 at 1:31 AM, Heikki Linnakangas
wrote:
Hmm, good point. It's harmless, but creating th
On 18.03.2011 10:48, Heikki Linnakangas wrote:
On 17.03.2011 21:39, Robert Haas wrote:
On Mon, Jan 31, 2011 at 10:45 PM, Fujii Masao
wrote:
On Tue, Feb 1, 2011 at 1:31 AM, Heikki Linnakangas
wrote:
Hmm, good point. It's harmless, but creating the history file in the
first
place sure seems lik
On 17.03.2011 21:39, Robert Haas wrote:
On Mon, Jan 31, 2011 at 10:45 PM, Fujii Masao wrote:
On Tue, Feb 1, 2011 at 1:31 AM, Heikki Linnakangas
wrote:
Hmm, good point. It's harmless, but creating the history file in the first
place sure seems like a waste of time.
The attached patch change
On Mon, Jan 31, 2011 at 10:45 PM, Fujii Masao wrote:
> On Tue, Feb 1, 2011 at 1:31 AM, Heikki Linnakangas
> wrote:
>> Hmm, good point. It's harmless, but creating the history file in the first
>> place sure seems like a waste of time.
>
> The attached patch changes pg_stop_backup so that it doesn
On Tue, Feb 1, 2011 at 1:31 AM, Heikki Linnakangas
wrote:
> Hmm, good point. It's harmless, but creating the history file in the first
> place sure seems like a waste of time.
The attached patch changes pg_stop_backup so that it doesn't create
the backup history file if archiving is not enabled.
On 27.01.2011 15:15, Fujii Masao wrote:
When I read the patch, I found that pg_stop_backup removes the backup history
file as soon as it creates the file, if archive_mode is not enabled.
This looks like
oversight. We should prevent pg_stop_backup from removing the fresh history
file? Or we should
On 25.01.2011 06:02, Fujii Masao wrote:
On Tue, Jan 25, 2011 at 6:02 AM, Heikki Linnakangas
wrote:
Hmm, perhaps the code would be more readable if instead of the
forcePageWrites counter that counts exclusive and non-exclusive backups, and
an exclusiveBackup boolean indicating if one of the in-
On Tue, Jan 25, 2011 at 1:02 PM, Fujii Masao wrote:
> On Tue, Jan 25, 2011 at 6:02 AM, Heikki Linnakangas
> wrote:
>> Hmm, perhaps the code would be more readable if instead of the
>> forcePageWrites counter that counts exclusive and non-exclusive backups, and
>> an exclusiveBackup boolean indica
On Tue, Jan 25, 2011 at 6:02 AM, Heikki Linnakangas
wrote:
> Hmm, perhaps the code would be more readable if instead of the
> forcePageWrites counter that counts exclusive and non-exclusive backups, and
> an exclusiveBackup boolean indicating if one of the in-progress backups is
> an exclusive one
On Tue, Jan 25, 2011 at 5:14 AM, Heikki Linnakangas
wrote:
>> I'm not entirely sure the replication privilege removal is correct.
>> Doing that, it's no longer possible to deploy a slave *without* using
>> pg_basebackup, unless you are superuser. Do we really want to put that
>> restriction back i
On 24.01.2011 22:31, Magnus Hagander wrote:
On Mon, Jan 24, 2011 at 21:14, Heikki Linnakangas
wrote:
On 24.01.2011 20:22, Magnus Hagander wrote:
I can't see an explicit check for the user ttempting to do
pg_stop_backup() when there is a nonexclusive backup running? Maybe
I'm reading it wrong?
On Mon, Jan 24, 2011 at 21:14, Heikki Linnakangas
wrote:
> On 24.01.2011 20:22, Magnus Hagander wrote:
>> I can't see an explicit check for the user ttempting to do
>> pg_stop_backup() when there is a nonexclusive backup running? Maybe
>> I'm reading it wrong? The case being when a user has starte
On 24.01.2011 20:22, Magnus Hagander wrote:
On Mon, Jan 24, 2011 at 17:52, Heikki Linnakangas
wrote:
Another updated patch. Fixed bitrot, and addressed the privilege issue
Fujii-san raised here:
http://archives.postgresql.org/message-id/4d380560.3040...@enterprisedb.com.
I changed the privileg
On Mon, Jan 24, 2011 at 17:52, Heikki Linnakangas
wrote:
> On 13.01.2011 23:32, Heikki Linnakangas wrote:
>>
>> Anyway, here's an updated patch with all the known issues fixed.
>
> Another updated patch. Fixed bitrot, and addressed the privilege issue
> Fujii-san raised here:
> http://archives.pos
On 13.01.2011 23:32, Heikki Linnakangas wrote:
Anyway, here's an updated patch with all the known issues fixed.
Another updated patch. Fixed bitrot, and addressed the privilege issue
Fujii-san raised here:
http://archives.postgresql.org/message-id/4d380560.3040...@enterprisedb.com.
I changed
On Thu, 2011-01-13 at 23:32 +0200, Heikki Linnakangas 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
> >> ob
On Thu, Jan 13, 2011 at 22:32, Heikki Linnakangas
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
>>> ob
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 se
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
On Thu, Jan 13, 2011 at 2:19 PM, Ross J. Reedstrom wrote:
> On Tue, Jan 11, 2011 at 11:06:18AM -0800, Josh Berkus wrote:
>>
>> > 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 streami
On Tue, Jan 11, 2011 at 11:06:18AM -0800, Josh Berkus wrote:
>
> > 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.
>
> Also, imag
On Wed, Jan 12, 2011 at 10:24:31AM -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 12.01.2011 17:15, David Fetter wrote:
> >> On Wed, Jan 12, 2011 at 10:26:05AM +0100, marcin mank wrote:
> >>> Considering that parallell base backups would be io-bound (or
> >>> network-bound), there is l
Heikki Linnakangas writes:
> On 12.01.2011 17:15, David Fetter wrote:
>> On Wed, Jan 12, 2011 at 10:26:05AM +0100, marcin mank wrote:
>>> Considering that parallell base backups would be io-bound (or
>>> network-bound), there is little need to actually run them in parallell
>>
>> That's not actua
On Wed, Jan 12, 2011 at 10:15 AM, David Fetter wrote:
>> Considering that parallell base backups would be io-bound (or
>> network-bound), there is little need to actually run them in parallell
>
> That's not actually true. Backups at the moment are CPU-bound, and
> running them in parallel is on
On Wed, Jan 12, 2011 at 05:17:38PM +0200, Heikki Linnakangas wrote:
> On 12.01.2011 17:15, David Fetter wrote:
> >On Wed, Jan 12, 2011 at 10:26:05AM +0100, marcin mank wrote:
> >>Considering that parallell base backups would be io-bound (or
> >>network-bound), there is little need to actually run t
On 12.01.2011 17:15, David Fetter wrote:
On Wed, Jan 12, 2011 at 10:26:05AM +0100, marcin mank wrote:
Considering that parallell base backups would be io-bound (or
network-bound), there is little need to actually run them in parallell
That's not actually true. Backups at the moment are CPU-bo
On Wed, Jan 12, 2011 at 10:26:05AM +0100, marcin mank wrote:
> On Tue, Jan 11, 2011 at 8:07 PM, Tom Lane wrote:
> > Magnus Hagander writes:
> >> On Tue, Jan 11, 2011 at 19:51, Tom Lane wrote:
> >>> Seems like either one of these is fairly problematic in that you have to
> >>> have some monstrous
On Tue, Jan 11, 2011 at 8:07 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Jan 11, 2011 at 19:51, Tom Lane 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 i
On 11.01.2011 23:51, Jeff Davis wrote:
On Tue, 2011-01-11 at 22:56 +0200, Heikki Linnakangas wrote:
1. If it's a primary recovering from a crash, and there is a
backup_label file, and the WAL referenced in the backup_label exists,
then it does a bunch of extra work during recovery; and
2.
2011/1/11 Heikki Linnakangas :
> On 11.01.2011 21:50, Dimitri Fontaine wrote:
>>
>> Heikki Linnakangas writes:
>>
>>> Now that we have a basic over-the-wire base backup capability in
>>> walsender,
>>> it would be nice to allow taking multiple base backups at the same time.
>>
>> I would prefer to
On Tue, 2011-01-11 at 23:07 +0100, Magnus Hagander wrote:
> I think keeping the flexibility is important. If it does add an extra
> step I think that's ok once we have pg_basebackup, but it must be
> reasonably *safe*. Corrupt backups from forgetting to exclude a file
> seems not so.
Agreed.
> B
On Tue, Jan 11, 2011 at 05:06:34PM -0500, Robert Haas wrote:
> On Jan 11, 2011, at 2:07 PM, Tom Lane wrote:
> > 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 we
On Jan 11, 2011, at 2:07 PM, Tom Lane wrote:
> 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.
I hope this assessment proves to be incorrect, because like
On Tue, Jan 11, 2011 at 22:51, Jeff Davis wrote:
> On Tue, 2011-01-11 at 22:56 +0200, Heikki Linnakangas wrote:
>> > 1. If it's a primary recovering from a crash, and there is a
>> > backup_label file, and the WAL referenced in the backup_label exists,
>> > then it does a bunch of extra work dur
On Tue, 2011-01-11 at 22:56 +0200, Heikki Linnakangas wrote:
> > 1. If it's a primary recovering from a crash, and there is a
> > backup_label file, and the WAL referenced in the backup_label exists,
> > then it does a bunch of extra work during recovery; and
> > 2. In the same situation, if th
On 11.01.2011 22:16, Jeff Davis wrote:
On Tue, 2011-01-11 at 20:17 +0200, Heikki Linnakangas wrote:
So, this patch modifies the internal do_pg_start/stop_backup functions
so that in addition to the traditional mode of operation, where a
backup_label file is created in the data directory where it
On Tue, 2011-01-11 at 20:17 +0200, Heikki Linnakangas wrote:
> So, this patch modifies the internal do_pg_start/stop_backup functions
> so that in addition to the traditional mode of operation, where a
> backup_label file is created in the data directory where it's backed up
> along with all oth
On 11.01.2011 21:50, Dimitri Fontaine wrote:
Heikki Linnakangas writes:
Now that we have a basic over-the-wire base backup capability in walsender,
it would be nice to allow taking multiple base backups at the same time.
I would prefer to be able to take a base backup from a standby, or is
t
Heikki Linnakangas writes:
> Now that we have a basic over-the-wire base backup capability in walsender,
> it would be nice to allow taking multiple base backups at the same time.
I would prefer to be able to take a base backup from a standby, or is
that already possible? What about cascading t
On 11.01.2011 20:17, Heikki Linnakangas wrote:
Patches for both approaches attached. They're also available in my
github repository at g...@github.com:hlinnaka/postgres.git.
Just so people won't report the same issues again, a couple of bugs have
already cropped up (thanks Magnus):
* a backu
Magnus Hagander writes:
> On Tue, Jan 11, 2011 at 19:51, Tom Lane 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
> 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.
Also, imagine that you're provisioning a 10-node replication cluster on
EC2. This
On 11.01.2011 20:51, Tom Lane wrote:
Heikki Linnakangas 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 tempora
On Tue, Jan 11, 2011 at 19:51, Tom Lane wrote:
> Heikki Linnakangas 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
Heikki Linnakangas 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
Now that we have a basic over-the-wire base backup capability in
walsender, it would be nice to allow taking multiple base backups at the
same time. It might not seem very useful at first, but it makes it
easier to set up standbys for small databases. At the moment, if you
want to set up two st
46 matches
Mail list logo
