Hi Thomas,
While testing one of the recovery scenarios I found one issue:
FailedAssertion("!(logno == context->recovery_logno)
The details of the same is mentioned below:
The context's try_location was not updated in
UndoLogAllocateInRecovery, in PrepareUndoInsert the try_location was
updated with the undo record size.
In the subsequent UndoLogAllocateInRecovery as the value for
try_location was not initialized but only updated with the size the
logno will always not match if the recovery_logno is non zero and the
assert fails.
Fixed by setting the try_location in UndoLogAllocateInRecovery,
similar to try_location setting in UndoLogAllocate.
Patch for the same is attached.
Please have a look and add the changes in one of the upcoming version.
Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
On Mon, Sep 2, 2019 at 9:53 AM Thomas Munro <[email protected]> wrote:
>
> On Fri, Aug 30, 2019 at 8:27 PM Kuntal Ghosh <[email protected]>
> wrote:
> > I'm getting the following assert failure while performing the recovery
> > with the same.
> > "TRAP: FailedAssertion("slot->meta.status == UNDO_LOG_STATUS_FULL",
> > File: "undolog.c", Line: 997)"
> >
> > I found that we don't emit an WAL record when we update the
> > slot->meta.status as UNDO_LOG_STATUS_FULL. If we don't that, after
> > crash recovery, some new transaction may use that undo log which is
> > wrong, IMHO. Am I missing something?
>
> Thanks, right, that status logging is wrong, will fix in next version.
>
> --
> Thomas Munro
> https://enterprisedb.com
>
>
From e69a9eea71562434cc0512871a9b6d7424ce93ec Mon Sep 17 00:00:00 2001
From: Vigneshwaran c <[email protected]>
Date: Fri, 30 Aug 2019 11:45:03 +0530
Subject: [PATCH] FailedAssertion("!(logno == context->recovery_logno) fix
try_location was not updated in UndoLogAllocateInRecovery, in
PrepareUndoInsert the try_location was updated with the undo record size.
In the subsequent UndoLogAllocateInRecovery as the value for try_location
was not initialized but only updated with the size the logno will always
not match if the recovery_logno is non zero and the assert fails. Fixed
by setting the try_location in UndoLogAllocateInRecovery, similar to
try_location setting in UndoLogAllocate.
Patch by Vigneshwaran C, reviewed by Dilip Kumar.
---
src/backend/access/undo/undolog.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/backend/access/undo/undolog.c b/src/backend/access/undo/undolog.c
index 073221c..9acd570 100644
--- a/src/backend/access/undo/undolog.c
+++ b/src/backend/access/undo/undolog.c
@@ -960,6 +960,14 @@ UndoLogAllocateInRecovery(UndoLogAllocContext *context,
*need_xact_header =
context->try_location == InvalidUndoRecPtr &&
slot->meta.unlogged.insert == slot->meta.unlogged.this_xact_start;
+
+ /*
+ * If no try_location was passed in, or if we switched logs, then we'll
+ * return the current insertion point.
+ */
+ if (context->try_location == InvalidUndoRecPtr)
+ context->try_location = MakeUndoRecPtr(slot->logno, slot->meta.unlogged.insert);
+
*last_xact_start = slot->meta.unlogged.last_xact_start;
context->recovery_logno = slot->logno;
--
1.8.3.1
