Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions - Mailing list pgsql-hackers
From | vignesh C |
---|---|
Subject | Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions |
Date | |
Msg-id | CALDaNm02dKYU6Kt8we9WeGgYWzpYvTSPkxU9hXqwzvCkNGATnw@mail.gmail.com Whole thread Raw |
In response to | Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Responses |
Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions |
List | pgsql-hackers |
On Tue, Oct 22, 2019 at 10:52 PM Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > > I think the patch should do the simplest thing possible, i.e. what it > does today. Otherwise we'll never get it committed. > I found a couple of crashes while reviewing and testing flushing of open transaction data: Issue 1: #0 0x00007f22c5722337 in raise () from /lib64/libc.so.6 #1 0x00007f22c5723a28 in abort () from /lib64/libc.so.6 #2 0x0000000000ec5390 in ExceptionalCondition (conditionName=0x10ea814 "!dlist_is_empty(head)", errorType=0x10ea804 "FailedAssertion", fileName=0x10ea7e0 "../../../../src/include/lib/ilist.h", lineNumber=458) at assert.c:54 #3 0x0000000000b4fb91 in dlist_tail_element_off (head=0x19e4db8, off=64) at ../../../../src/include/lib/ilist.h:458 #4 0x0000000000b546d0 in ReorderBufferAbortOld (rb=0x191b6b0, oldestRunningXid=3834) at reorderbuffer.c:1966 #5 0x0000000000b3ca03 in DecodeStandbyOp (ctx=0x19af990, buf=0x7ffcbc26dc50) at decode.c:332 #6 0x0000000000b3c208 in LogicalDecodingProcessRecord (ctx=0x19af990, record=0x19afc50) at decode.c:121 #7 0x0000000000b7109e in XLogSendLogical () at walsender.c:2845 #8 0x0000000000b6f5e4 in WalSndLoop (send_data=0xb70f77 <XLogSendLogical>) at walsender.c:2199 #9 0x0000000000b6c7e1 in StartLogicalReplication (cmd=0x1983168) at walsender.c:1128 #10 0x0000000000b6da6f in exec_replication_command (cmd_string=0x18f70a0 "START_REPLICATION SLOT \"sub1\" LOGICAL 0/0 (proto_version '1', publication_names '\"pub1\"')") at walsender.c:1545 Issue 2: #0 0x00007f1d7ddc4337 in raise () from /lib64/libc.so.6 #1 0x00007f1d7ddc5a28 in abort () from /lib64/libc.so.6 #2 0x0000000000ec4e1d in ExceptionalCondition (conditionName=0x10ead30 "txn->final_lsn != InvalidXLogRecPtr", errorType=0x10ea284 "FailedAssertion", fileName=0x10ea2d0 "reorderbuffer.c", lineNumber=3052) at assert.c:54 #3 0x0000000000b577e0 in ReorderBufferRestoreCleanup (rb=0x2ae36b0, txn=0x2bafb08) at reorderbuffer.c:3052 #4 0x0000000000b52b1c in ReorderBufferCleanupTXN (rb=0y x2ae36b0, txn=0x2bafb08) at reorderbuffer.c:1318 #5 0x0000000000b5279d in ReorderBufferCleanupTXN (rb=0x2ae36b0, txn=0x2b9d778) at reorderbuffer.c:1257 #6 0x0000000000b5475c in ReorderBufferAbortOld (rb=0x2ae36b0, oldestRunningXid=3835) at reorderbuffer.c:1973 #7 0x0000000000b3ca03 in DecodeStandbyOp (ctx=0x2b676d0, buf=0x7ffcbc74cc00) at decode.c:332 #8 0x0000000000b3c208 in LogicalDecodingProcessRecord (ctx=0x2b676d0, record=0x2b67990) at decode.c:121 #9 0x0000000000b70b2b in XLogSendLogical () at walsender.c:2845 These failures come randomly. I'm not able to reproduce this issue with simple test case. I have attached the test case which I used to test. I will further try to find a scenario which could reproduce consistently. Posting it so that it can help someone in identifying the problem parallelly through code review by experts. Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com
Attachment
pgsql-hackers by date: