On Sat, Jul 27, 2013 at 12:51 AM, Fujii Masao wrote:
> On Fri, Jul 26, 2013 at 11:55 PM, Andres Freund
> wrote:
>> On 2013-07-26 23:47:59 +0900, Fujii Masao wrote:
>>> >> If this problem is solved, there is possible of that we can failback
>>> >> by removing the all WAL record which is in pg_xlo
On Fri, Jul 26, 2013 at 11:55 PM, Andres Freund wrote:
> On 2013-07-26 23:47:59 +0900, Fujii Masao wrote:
>> >> If this problem is solved, there is possible of that we can failback
>> >> by removing the all WAL record which is in pg_xlog before server
>> >> starts as the slave server.
>> >> ( And
On 2013-07-26 23:47:59 +0900, Fujii Masao wrote:
> >> If this problem is solved, there is possible of that we can failback
> >> by removing the all WAL record which is in pg_xlog before server
> >> starts as the slave server.
> >> ( And we also use "synchronous_transfer" which I'm proposing, I thin
On Fri, Jul 26, 2013 at 3:08 PM, Andres Freund wrote:
> Hi,
>
> On 2013-07-26 13:19:34 +0900, Sawada Masahiko wrote:
>> When the slave server starts, the slave server perform the following
>> steps in StartupXLOG():
>> 1. Read latest CheckPoint record LSN from pg_control file.
>> 2. Try to fetch C
Hi,
On 2013-07-26 13:19:34 +0900, Sawada Masahiko wrote:
> When the slave server starts, the slave server perform the following
> steps in StartupXLOG():
> 1. Read latest CheckPoint record LSN from pg_control file.
> 2. Try to fetch CheckPoint record from pg_xlog directory at first.
> ( The serv
Hi All,
When the slave server starts, the slave server perform the following
steps in StartupXLOG():
1. Read latest CheckPoint record LSN from pg_control file.
2. Try to fetch CheckPoint record from pg_xlog directory at first.
( The server try to read up to prior CheckPoint record from pg_contrl