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 spot that
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
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
Hello,
At Fri, 28 Feb 2014 14:45:58 +0200, Heikki Linnakangas
hlinnakan...@vmware.com 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
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 the
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 problem
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. Starting
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
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:
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 stop -m i
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 $PGDATA/*
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.
12 matches
Mail list logo