Skip site navigation (1) Skip section navigation (2)

Re: Re: BUG #5602: Recovering from Hot-Standby file backup leads to the currupted indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Valentine Gogichashvili <valgog(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Re: BUG #5602: Recovering from Hot-Standby file backup leads to the currupted indexes
Date: 2010-08-12 14:53:15
Message-ID: 14092.1281624795@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> On Thu, Aug 12, 2010 at 5:33 PM, Valentine Gogichashvili
> <valgog(at)gmail(dot)com> 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 full_page_writes
> is disabled. So we should:

> (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 while backup_label
>    exists in standby?), so backup_label should be copied to elsewhere
>    than standby.
> 3. wait for "Latest checkpoint's REDO location" which pg_controldata
>    on standby returns, to reach or exceed "START WAL LOCATION" in
>    backup_label copied in the step 2. This would take long, but we
>    can run checkpoint on standby to shorten waiting time.

Hm, can you actually execute CHECKPOINT on a HS slave?  Is it guaranteed
to cause a restartpoint to be created?

> 4. run backup on standby
> 5. run pg_stop_backup() on master
> 6. copy backup_label from temporary are to backup

> Is this procedure still unsafe?

This still isn't doing anything to address the problem I'm worried
about, which is when does the copy actually reach consistency.  The
above procedure might guarantee that it eventually will reach
consistency, but you don't know when it has.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Robert HaasDate: 2010-08-12 15:05:29
Subject: Re: BUG #5611: SQL Function STABLE promoting to VOLATILE
Previous:From: Tom LaneDate: 2010-08-12 14:44:56
Subject: Re: BUG #5611: SQL Function STABLE promoting to VOLATILE

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group