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

Re: Online base backup from the hot-standby

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Steve Singer <ssinger_pg(at)sympatico(dot)ca>
Cc: Jun Ishiduka <ishizuka(dot)jun(at)po(dot)ntts(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, cedric(dot)villemain(dot)debian(at)gmail(dot)com, robertmhaas(at)gmail(dot)com, magnus(at)hagander(dot)net, heikki(dot)linnakangas(at)enterprisedb(dot)com
Subject: Re: Online base backup from the hot-standby
Date: 2011-09-28 01:58:19
Message-ID: CAHGQGwF_EXt_RMLw8ZUAFY3A_eWy7Xa3L4hATyUo=e-F31JMuA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Sep 28, 2011 at 8:10 AM, Steve Singer <ssinger_pg(at)sympatico(dot)ca> wrote:
> This is the test procedure I'm trying today, I wasn't able to reproduce the
> crash.  What I was doing the other day was similar but I can't speak to
> unintentional differences.

Thanks for the info! I tried your test case three times, but was not able to
reproduce the issue, too.

BTW, I created the shell script (attached) which runs your test scenario and
used it for the test.

If the issue will happen again, please feel free to share the information about
it. I will diagnose it.

> It looks like data3 is still pulling files with the recovery command after
> it sees the touch file (is this expected behaviour?)

Yes, that's expected behavior. After the trigger file is found, PostgreSQL
tries to replay all available WAL files in pg_xlog directory and archive one.
So, if there is unreplayed archived WAL file at that time, PostgreSQL tries
to pull it by calling the recovery command.

And, after WAL replay is done, PostgreSQL tries to re-fetch the last
replayed WAL record in order to identify the end of replay location. So,
if the last replayed record is included in the archived WAL file, it's pulled
by the recovery command.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Attachment: test.sh
Description: application/x-sh (2.2 KB)

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-09-28 02:40:28
Subject: Re: pg_upgrade automatic testing
Previous:From: Tom LaneDate: 2011-09-28 01:55:41
Subject: Re: [PATCH] Log crashed backend's query v2

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