Hello,
> > After all, I have confirmed that this fixes the problem on crash
> > recovery of hot-standby botfor 9.3 and HEAD and no problem was
> > found except unreadability :(
>
> Ok, committed. Thanks!
Thank you.
> Any concrete suggestions about the readability? Is there some
> particular spo
On 03/05/2014 10:51 AM, Kyotaro HORIGUCHI wrote:
Hello,
After all, I have confirmed that this fixes the problem on crash
recovery of hot-standby botfor 9.3 and HEAD and no problem was
found except unreadability :(
Ok, committed. Thanks!
Any concrete suggestions about the readability? Is there
Hello,
After all, I have confirmed that this fixes the problem on crash
recovery of hot-standby botfor 9.3 and HEAD and no problem was
found except unreadability :(
By the way, I moderately want to fix an assertion message to a
ordinary one. Details are below.
The server stops with followi
Hello,
> | * as if we had just replayed the record before the REDO location
> | * (or the checkpoint record itself, if it's a shutdown checkpoint).
>
> The test script following raises assertion failure. It's added
> with 'non-shutdown' checkpoint' just before shutting down
> immediately. Startin
Correcting one point of my last mail.
> Ouch! It brought another bug.
My patch also did.
regards,
> > I completely understood the behavior thanks to your detailed
> > explanation. (And how to use log messages effectively :-)
>
> Sorry, I just found that it's wrong, and found another probl
Ouch! It brought another bug.
> I completely understood the behavior thanks to your detailed
> explanation. (And how to use log messages effectively :-)
Sorry, I just found that it's wrong, and found another problem
brought by your patch.
> I agree that the fix is appropriate.
>
> > I believe t
Hello,
At Fri, 28 Feb 2014 14:45:58 +0200, Heikki Linnakangas
wrote in <53108506.2010...@vmware.com>
> > Yes, but the same stuation could be made by restarting crashed
> > secondary.
>
> Yeah.
>
> > I have no idea about the scenario on whitch this behavior was regarded
> > as
> > undesirable b
On 02/28/2014 11:51 AM, Kyotaro HORIGUCHI wrote:
Hello,
2014/02/28 18:07 "Andres Freund" :
On 2014-02-28 17:55:21 +0900, Kyotaro HORIGUCHI wrote:
The recovery process stays on 'incosistent' state forever when
the server has crashed before any wal record is inserted after
the last checkpoint.
Hello,
2014/02/28 18:07 "Andres Freund" :
>
> On 2014-02-28 17:55:21 +0900, Kyotaro HORIGUCHI wrote:
> > The recovery process stays on 'incosistent' state forever when
> > the server has crashed before any wal record is inserted after
> > the last checkpoint.
>
> > # killall postgres
> > # rm -rf
On 2014-02-28 17:55:21 +0900, Kyotaro HORIGUCHI wrote:
> The recovery process stays on 'incosistent' state forever when
> the server has crashed before any wal record is inserted after
> the last checkpoint.
> # killall postgres
> # rm -rf $PGDATA/*
> initdb
> pg_ctl start -w
> sleep 1
> pg_ctl st
Ouch. this is the same issue to the mail below,
http://www.postgresql.org/message-id/53104595.6060...@lab.ntt.co.jp
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
Hello, we found that hot standby doesn't came up under certain
condition. This occurs for 9.3 and 9.4dev.
The recovery process stays on 'incosistent' state forever when
the server has crashed before any wal record is inserted after
the last checkpoint.
This seems to be because EndRecPtr is set to
12 matches
Mail list logo