Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VG42V-0002Vc-Nw for pgsql-admin@arkaria.postgresql.org; Sun, 01 Sep 2013 09:33:48 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VG42U-0001ot-0T for pgsql-admin@arkaria.postgresql.org; Sun, 01 Sep 2013 09:33:46 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VG42R-0001ok-FU for pgsql-admin@postgresql.org; Sun, 01 Sep 2013 09:33:43 +0000 Received: from nm22-vm6.bullet.mail.sg3.yahoo.com ([106.10.151.53]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VG42N-0005AH-GX for pgsql-admin@postgresql.org; Sun, 01 Sep 2013 09:33:42 +0000 Received: from [106.10.166.61] by nm22.bullet.mail.sg3.yahoo.com with NNFMP; 01 Sep 2013 09:33:37 -0000 Received: from [106.10.151.250] by tm18.bullet.mail.sg3.yahoo.com with NNFMP; 01 Sep 2013 09:33:36 -0000 Received: from [127.0.0.1] by omp1021.mail.sg3.yahoo.com with NNFMP; 01 Sep 2013 09:33:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 960445.49072.bm@omp1021.mail.sg3.yahoo.com Received: (qmail 15084 invoked by uid 60001); 1 Sep 2013 09:33:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.hk; s=s1024; t=1378028014; bh=XW9kA1kwVRmvXAjchZLwJHGPsGGdHCQv/ZajM28wUhQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=TwOeNfQPiwUaeD/Oyd7Rb8NH8XvbrMMw0+13XbfcWHJQ/ZWJsK6XYWuABKq/nCYadvXXahDf3VQ2/ziIdA5o+LKvZAQicpwZlJsYmApf5DcJNCd1HZAfeHXYmHbPnLYBOy1mGfadWzM/teh6AkgixyCcvtyLtbt0mOamI9n7yBc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.hk; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=xxexWUFPP0BXMtlyFf69wIToqLXv4Fl068EcWGfqtZc/1p0g4S4/1LJpKXOa9hDjXIChdOeBqJIJv3ateBNFj/ViwJpJnv8DTtcbk6SCOZh6xpkyUWBjb5s0KylfoG7yAX+hBhOSw/2HOpVCDKJCsWWzJP6YPnAzKwvRW5Tdkkk=; X-YMail-OSG: kc9t7ioVM1n9pAU_Tn_ybZfFKwH_uGfuMzsv_dNUwP3oGE. WErUeg9rGHb30VDtVGsDNssemfWYkf3FLXt7FExisI5lZtKHRQaQEJq7PAPY ns60KnlpMJj_GR4fDpi72EwNutLytgv1DCzEy8db805ossEAbyLDfy_Z7Y5J Wt0b4hzTwkfu3tTynX4TiG4HjI8xryW2j6TotUuBF5tq9vrKgUyYASSR2hJ4 VdTF4bvPzq8TAXBYG.vkWPXpwU3jfv8ouzLoAR1u4V.3yQfGdsaicKs1ICQW Yd_.ZXsiMNK49QPb7lygNm.re4t9efT50LrEJnAb5sVMiCH1IViJs16pcUqM asH.IHGYlL8eRXmJgiBSWnmb5H8RxGqCAaGI8wTo9Q7mmpItRFxxz.ueDcop ZWXAs1aH18p5nrdAuL9YufrDTdQewWlZthfnC.6fgu8AnugLIYSV5qB.sN9i Ooz7pDA2NxlQJvYwWr5_c9DdbuAWx1FwOl_f0n1XYW8VdVGpWEKhweEMeGBG 9ucGHURBcLh5MJYrGBE3w3spA_aTN68zJ2CK7XLvFt2BT5A197ti0px9CED1 85LDx5kJzhJMBvoK04XGAEsdqu6iGSxTeusnl.kqGGNsvgQo_vSKb8WBgxmo iVoE- Received: from [61.15.240.116] by web193502.mail.sg3.yahoo.com via HTTP; Sun, 01 Sep 2013 17:33:33 SGT X-Rocket-MIMEInfo: 002.001, J0NyYXNoIGNvbnNpc3RlbnQnIGlzIGEgdGVybSBJIGhlYXJkIGluIHNvbWUgb3JhY2xlIHdoaXRlIHBhcGVycy4uCklmIEkgYW0gY29ycmVjdCwgaXQgbWVhbnMgdGhlIGRhdGFiYXNlIHdvdWxkIGJlIGNvbnNpc3RlbnQgYWZ0ZXIgdGhlIGNyYXNoIHJlY292ZXJ5IGlzIGRvbmUuCgoKPj4gV2hpY2ggbWVhbnMgaXQgaXMgY29uc2lzdGVudCBhdCB0aGUgdGltZSB0aGF0IHRoZSBwZ19zdGFydF9iYWNrdXAKPj4gaXMgcnVuLgoKPk5vLsKgIEl0IHdpbGwgYmUgY29uc2lzdGVudCB3aXRoIHRoZSB0aW1lIHRoYXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 References: <1377186808.57546.YahooMailNeo@web193505.mail.sg3.yahoo.com> <1377494614.9111.YahooMailNeo@web193506.mail.sg3.yahoo.com> <1377631895.15061.YahooMailNeo@web162901.mail.bf1.yahoo.com> Message-ID: <1378028013.14431.YahooMailNeo@web193502.mail.sg3.yahoo.com> Date: Sun, 1 Sep 2013 17:33:33 +0800 (SGT) From: Patrick Dung Reply-To: Patrick Dung Subject: Re: several questions about pg_dumpall, pg_start_backup, pg_basebackup and WAL To: Kevin Grittner , Albe Laurenz , "pgsql-admin@postgresql.org" In-Reply-To: <1377631895.15061.YahooMailNeo@web162901.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-507039889-1648758452-1378028013=:14431" X-Pg-Spam-Score: 0.7 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org ---507039889-1648758452-1378028013=:14431 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 'Crash consistent' is a term I heard in some oracle white papers..=0AIf I a= m correct, it means the database would be consistent after the crash recove= ry is done.=0A=0A=0A>> Which means it is consistent at the time that the pg= _start_backup=0A>> is run.=0A=0A>No.=A0 It will be consistent with the time= that pg_stop_backup was=0A>run, or any later point in time that you choose= , as long as you=0A>have WAL to that point in time.=0AIn the manual, we whe= re told to do three steps:=0A1) pg_start_backup=0A=0A2) backup by tar=0A3) = pg_stop_backup=0AIf the backup is consistent when pg_stop_backup is called,= I think it worth to mention it in the manual.=0A=0A=0AThanks and regards,= =0APatrick Dung=0A=0A=0A=0A________________________________=0A From: Kevin = Grittner =0ATo: Patrick Dung ;= Albe Laurenz ; "pgsql-admin@postgresql.org" =0ASent: Wednesday, August 28, 2013 3:31 AM=0ASubje= ct: Re: [ADMIN] several questions about pg_dumpall, pg_start_backup, pg_bas= ebackup and WAL=0A =0A=0APatrick Dung wrote:=0A>= Albe Laurenz =0A>> Patrick Dung wrote:=0A=0A>>> I= t is possible that there is file changes (added or file size=0A>>> changed)= between the pg_start_backup and pg_stop_backup.=0A>>=0A>> Yes.=0A>>=0A>>> = Is the backup consistent?=0A>>=0A>> The tar or snapshot itself will not be = consistent, it will have=0A>> to be recovered at least until the end on the= online backup.=0A>=0A> I should ask: is the backup crash consistent?=0A=0A= PITR restore procedures will use the crash recovery mechanism to=0Amake the= database consistent, if that's what you mean.=0A=0A> Which means it is con= sistent at the time that the pg_start_backup=0A> is run.=0A=0ANo.=A0 It wil= l be consistent with the time that pg_stop_backup was=0Arun, or any later p= oint in time that you choose, as long as you=0Ahave WAL to that point in ti= me.=0A=0A--=0AKevin Grittner=0AEDB: http://www.enterprisedb.com=0AThe Enter= prise PostgreSQL Company=0A=0A=0A-- =0ASent via pgsql-admin mailing list (p= gsql-admin@postgresql.org)=0ATo make changes to your subscription:=0Ahttp:/= /www.postgresql.org/mailpref/pgsql-admin ---507039889-1648758452-1378028013=:14431 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
'Crash consisten= t' is a term I heard in some oracle white papers..
If I am correc= t, it means the database would be consistent after the crash recovery is do= ne.

>> Which means it is consistent at the time tha= t the pg_start_backup
>> is run.

>No.  It will be c= onsistent with the time that pg_stop_backup was
>run, or any later po= int in time that you choose, as long as you
>have WAL to that point i= n time.

In the manual, we where told to do three steps:
1) pg_start_backup
2) backup by tar
3) = pg_stop_backup

If the backup is consistent when pg_stop= _backup is called, I think it worth to mention it in the manual.
Thanks and regards,
Patrick Dung

=

From:<= /b> Kevin Grittner <kgrittn@ymail.com>
To: Patrick Dung <patrick_dkt@yahoo.com.hk>; A= lbe Laurenz <laurenz.albe@wien.gv.at>; "pgsql-admin@postgresql.org" &= lt;pgsql-admin@postgresql.org>
Subject: Re: [ADMIN] several questions abou= t pg_dumpall, pg_start_backup, pg_basebackup and WAL

Patrick Dung <patrick_dkt@yahoo.com.hk> wrote:
> Albe Laurenz <= ;laurenz.albe@wien.gv.at>
>> Patrick Dung wrote:=

>>> It is possible that there is file changes (added or fi= le size
>>> changed) between the pg_start_backup and pg_stop_ba= ckup.
>>
>> Yes.
>>
>>> Is the backu= p consistent?
>>
>> The tar or snapshot itself will not b= e consistent, it will have
>> to be recovered at least until the e= nd on the online backup.
>
> I should ask: is the backup crash = consistent?

PITR restore procedures will use the crash recovery mech= anism to
make the database consistent, if that's what you mean.

&= gt; Which means it is consistent at the time that the pg_start_backup
> is run.

No.  It will be consistent wit= h the time that pg_stop_backup was
run, or any later point in time that = you choose, as long as you
have WAL to that point in time.

--
= Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company=


--
Sent via pgsql-admin mailing list (pgsq= l-admin@postgresql.org)
To make changes to your subscription:
h= ttp://www.postgresql.org/mailpref/pgsql-admin

---507039889-1648758452-1378028013=:14431--