On Thu, Aug 12, 2010 at 11:53 PM, Tom Lane wrote:
>> (based on Simon's suggestion)
>> 1. run pg_start_backup() on master.
>> 2. copy backup_label from master to temporary area.
>> copying backup_label directly to standby would generate another
>> weakness (e.g., what if standby is restarted
Fujii Masao writes:
> On Thu, Aug 12, 2010 at 5:33 PM, Valentine Gogichashvili
> wrote:
>> Actually full_page_write being turned off on the master is probably a
>> problem.
> Yep. As Simon suggests, we must run pg_start_backup on the master,
> to take a backup from the standby safely even if ful
On Thu, Aug 12, 2010 at 5:33 PM, Valentine Gogichashvili
wrote:
> Hi,
> Actually full_page_write being turned off on the master is probably a
> problem.
Yep. As Simon suggests, we must run pg_start_backup on the master,
to take a backup from the standby safely even if full_page_writes
is disabled
Hi,
Actually full_page_write being turned off on the master is probably a
problem.
-- Valentine
On Thu, Aug 12, 2010 at 9:43 AM, Fujii Masao wrote:
> On Thu, Aug 12, 2010 at 4:18 PM, Simon Riggs
> wrote:
> > The safest approach is to
> >
> > 1. run pg_start_backup() on master, remember LSN
>
On Thu, Aug 12, 2010 at 4:18 PM, Simon Riggs wrote:
> The safest approach is to
>
> 1. run pg_start_backup() on master, remember LSN
> 2. copy backup_label from master to standby
> 3. wait for starting LSN to be applied on standby
ISTM we should wait for the latest checkpoint redo location to rea
On Thu, Aug 12, 2010 at 2:31 PM, Tom Lane wrote:
> What was bothering me about the procedure is that it's not clear when
> the new slave has reached consistency, in the sense of having used WAL
> to clean up any out-of-sync conditions in the base backup it was started
> from. So you can't be sure
On Thu, 2010-08-12 at 01:31 -0400, Tom Lane wrote:
> So the DBA is
> just flying blind as to whether the slave is trustworthy yet. I can't
> prove that that's what burnt the original complainant, but it fits the
> symptoms.
The safest approach is to
1. run pg_start_backup() on master, remember
Fujii Masao writes:
> On Fri, Aug 6, 2010 at 7:50 AM, Simon Riggs wrote:
>> The procedure used does differ from that documented. However, IMHO the
>> procedure *documented* is *not* safe and could lead to corrupt indexes
>> in the way described, since the last recovered point might be mid-way
>>
On Fri, Aug 6, 2010 at 7:50 AM, Simon Riggs wrote:
> The procedure used does differ from that documented. However, IMHO the
> procedure *documented* is *not* safe and could lead to corrupt indexes
> in the way described, since the last recovered point might be mid-way
> between two halves of an in
Hi all,
the procedure that waits for the checkpoint location change looks
like::
function wait_for_checkpoint_location_change() {
PRE_WAIT=$( pg_controldata $PGDATA | awk -F: '/Latest checkpoint
location/ { print $2 }' )
log "Waiting for checkpoint"
while true ; do
sleep 5
On Fri, Aug 6, 2010 at 12:20 PM, Tom Lane wrote:
> Hm, I was looking at that and thinking it seemed unsafe for entirely
> different reasons. But if you didn't write it, who did?
Incrementally Updated Backups technique has been in the document since 8.2.
In the development cycle of 9.0, I and Hei
Simon Riggs writes:
> On Thu, 2010-08-05 at 11:28 -0700, valgog wrote:
>> It was done as documented in
>> http://www.postgresql.org/docs/9.0/static/backup-incremental-updated.html
> The procedure used does differ from that documented. However, IMHO the
> procedure *documented* is *not* safe and
On Thu, 2010-08-05 at 11:28 -0700, valgog wrote:
> > This process seems almost entirely unrelated to the documented way of
> > doing it; I'm not surprised that you end up with some files not in sync.
> > Please see pg_start_backup and friends.
> It was done as documented in
> http://www.postgresq
valgog writes:
>> This process seems almost entirely unrelated to the documented way of
>> doing it; I'm not surprised that you end up with some files not in sync.
>> Please see pg_start_backup and friends.
> It was done as documented in
> http://www.postgresql.org/docs/9.0/static/backup-increme
> This process seems almost entirely unrelated to the documented way of
> doing it; I'm not surprised that you end up with some files not in sync.
> Please see pg_start_backup and friends.
>
> regards, tom lane
>
Hallo Tom,
It was done as documented in
http://www.postgre
15 matches
Mail list logo
