On Wed, Dec 12, 2012 at 2:03 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 11.12.2012 17:04, Fujii Masao wrote:
The patch looks good. I confirmed that the PANIC error didn't happen,
with the patch.
Ok, committed, and also moved the CheckRecoveryConsistency call. Please take
a
On 11.12.2012 08:07, Kyotaro HORIGUCHI wrote:
The cause is that CheckRecoveryConsistency() is called before rm_redo(),
as Horiguchi-san suggested upthead. Imagine the case where
minRecoveryPoint is set to the location of the XLOG_SMGR_TRUNCATE
record. When restarting the server with that
On Tue, Dec 11, 2012 at 6:14 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 11.12.2012 08:07, Kyotaro HORIGUCHI wrote:
The cause is that CheckRecoveryConsistency() is called before rm_redo(),
as Horiguchi-san suggested upthead. Imagine the case where
minRecoveryPoint is set to the
On 11.12.2012 17:04, Fujii Masao wrote:
On Tue, Dec 11, 2012 at 6:14 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 11.12.2012 08:07, Kyotaro HORIGUCHI wrote:
The cause is that CheckRecoveryConsistency() is called before rm_redo(),
as Horiguchi-san suggested upthead. Imagine the
On 11.12.2012 17:04, Fujii Masao wrote:
The patch looks good. I confirmed that the PANIC error didn't happen,
with the patch.
Ok, committed, and also moved the CheckRecoveryConsistency call. Please
take a look to double-check that I didn't miss anything.
- Heikki
--
Sent via pgsql-hackers
Monday, December 10, 2012 7:16 AM Kyotaro HORIGUCHI wrote:
Thank you.
I think moving CheckRecoveryConsistency() after redo apply loop might
cause
a problem.
As currently it is done before recoveryStopsHere() function, which can
allow
connections
on HOTSTANDY. But now if due to some
On 10.12.2012 03:52, Kyotaro HORIGUCHI wrote:
I think that minRecoveryPoint should be updated before the data-file
changes, so XLogFlush() should be called before smgrtruncate(). No?
Mmm.. As far as I saw in xact_redo_commit_internal, XLogFlush
seems should be done AFTER redo substantial
On 10.12.2012 13:50, Heikki Linnakangas wrote:
So I'd say we should update minRecoveryPoint first, then
truncate/delete. But we should still keep the XLogFlush() at the end of
xact_redo_commit_internal(), for the case where files/directories are
created. Patch attached.
Committed and
On Tue, Dec 11, 2012 at 1:33 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 10.12.2012 13:50, Heikki Linnakangas wrote:
So I'd say we should update minRecoveryPoint first, then
truncate/delete. But we should still keep the XLogFlush() at the end of
xact_redo_commit_internal(), for
Hello, I've also found this does not fix this problem.
So I'd say we should update minRecoveryPoint first, then
truncate/delete. But we should still keep the XLogFlush() at the end of
xact_redo_commit_internal(), for the case where files/directories are
created. Patch attached.
Sounds
On Thu, Dec 6, 2012 at 8:39 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Thursday, December 06, 2012 9:35 AM Kyotaro HORIGUCHI wrote:
Hello, I have a problem with PostgreSQL 9.2 with Pacemaker.
HA standby sometime failes to start under normal operation.
Testing with a bare replication
On Thu, Dec 6, 2012 at 1:04 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
diff --git a/src/backend/catalog/storage.c b/src/backend/catalog/storage.c
index 993bc49..d34ab65 100644
--- a/src/backend/catalog/storage.c
+++ b/src/backend/catalog/storage.c
@@ -519,6 +519,12 @@
Thank you.
I think moving CheckRecoveryConsistency() after redo apply loop might cause
a problem.
As currently it is done before recoveryStopsHere() function, which can allow
connections
on HOTSTANDY. But now if due to some reason recovery pauses or stops due to
above function,
Hello,
I think that minRecoveryPoint should be updated before the data-file
changes, so XLogFlush() should be called before smgrtruncate(). No?
Mmm.. As far as I saw in xact_redo_commit_internal, XLogFlush
seems should be done AFTER redo substantial operation. Is it
wrong? If so, I suppose
On Thursday, December 06, 2012 9:35 AM Kyotaro HORIGUCHI wrote:
Hello, I have a problem with PostgreSQL 9.2 with Pacemaker.
HA standby sometime failes to start under normal operation.
Testing with a bare replication pair showed that the standby failes
startup recovery under the operation
15 matches
Mail list logo
