Re: Online base backup from the hot-standby - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Online base backup from the hot-standby
Date
Msg-id CAHGQGwF_EXt_RMLw8ZUAFY3A_eWy7Xa3L4hATyUo=e-F31JMuA@mail.gmail.com
Whole thread Raw
In response to Re: Online base backup from the hot-standby  (Steve Singer <ssinger_pg@sympatico.ca>)
List pgsql-hackers
On Wed, Sep 28, 2011 at 8:10 AM, Steve Singer <ssinger_pg@sympatico.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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Log crashed backend's query v2
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade automatic testing