FailedAssertion at ReorderBufferCheckMemoryLimit()

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: FailedAssertion at ReorderBufferCheckMemoryLimit()
Date: 2020-06-09 08:26:24
Message-ID: 2b7ba291-22e0-a187-d167-9e5309a3458d@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I encountered the following assertion failure when I changed
logical_decoding_work_mem to lower value while logical replication
is running. This happend in the master branch.

TRAP: FailedAssertion("rb->size < logical_decoding_work_mem * 1024L", File: "reorderbuffer.c", Line: 2403)
0 postgres 0x000000010755bf80 ExceptionalCondition + 160
1 postgres 0x00000001072d9f81 ReorderBufferCheckMemoryLimit + 257
2 postgres 0x00000001072d9b74 ReorderBufferQueueChange + 228
3 postgres 0x00000001072cd107 DecodeInsert + 391
4 postgres 0x00000001072cc4ef DecodeHeapOp + 335
5 postgres 0x00000001072cb9e4 LogicalDecodingProcessRecord + 196
6 postgres 0x000000010730bf06 XLogSendLogical + 166
7 postgres 0x000000010730b409 WalSndLoop + 217
8 postgres 0x00000001073075fc StartLogicalReplication + 716
9 postgres 0x0000000107305d38 exec_replication_command + 1192
10 postgres 0x000000010737ea7f PostgresMain + 2463
11 postgres 0x00000001072a9c4a BackendRun + 570
12 postgres 0x00000001072a907b BackendStartup + 475
13 postgres 0x00000001072a7fe1 ServerLoop + 593
14 postgres 0x00000001072a5a5a PostmasterMain + 5898
15 postgres 0x0000000107187b59 main + 761
16 libdyld.dylib 0x00007fff6c00c3d5 start + 1

ReorderBufferCheckMemoryLimit() explains that it relies on
the following (commented) assumption. But this seems incorrect
when logical_decoding_work_mem is decreased. I wonder if we may
need to keep evicting the transactions until we don't exceed
memory limit.

/*
* And furthermore, evicting the transaction should get us below the
* memory limit again - it is not possible that we're still exceeding the
* memory limit after evicting the transaction.
*
* This follows from the simple fact that the selected transaction is at
* least as large as the most recent change (which caused us to go over
* the memory limit). So by evicting it we're definitely back below the
* memory limit.
*/
Assert(rb->size < logical_decoding_work_mem * 1024L);

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2020-06-09 08:27:12 Re: WIP: Generic functions for Node types using generated metadata
Previous Message Magnus Hagander 2020-06-09 08:24:21 Re: Resetting spilled txn statistics in pg_stat_replication