Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g8KCJ-0005bO-Ey for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Oct 2018 07:06:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g8KCH-0001mo-UO for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Oct 2018 07:06:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g8KCH-0001mM-Jg for pgsql-hackers@lists.postgresql.org; Fri, 05 Oct 2018 07:06:49 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g8KCF-000553-Er for pgsql-hackers@postgresql.org; Fri, 05 Oct 2018 07:06:49 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 5FE0121C2A8C for ; Fri, 5 Oct 2018 10:06:46 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[] autolearn=unavailable Received: from [192.168.0.37] (unknown [92.243.182.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 31EA921C2A57 for ; Fri, 5 Oct 2018 10:06:46 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1538723206; bh=sU1+FhtsR26sxQP49YIAVhGNSifyvYaif56IrPVed98=; h=To:From:Subject:Date; b=ijyqZAFtjeASXaGJZs7PIWStBYlxsJXia1Y4boTHY97vnVRhHTkweKGjbjhCYJMKI V8EQe+SQWEdYXRAnj2CLl7BX1JBmk9IvDhRDTE1IPpFqkd/fx49Csg4l1v7+GJWIMi Ask4OODTeg2dpV6Yz98JIa5sb1Uw+zGQXpioy+1Q= To: PostgreSQL Hackers From: Konstantin Knizhnik Subject: out-of-order XID insertion in KnownAssignedXids Message-ID: <0c96b653-4696-d4b4-6b5d-78143175d113@postgrespro.ru> Date: Fri, 5 Oct 2018 10:06:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi hackers, Looks like there is a bug with logging running transactions XIDs and prepared transactions. One of our customers get error "FATAL: out-of-order XID insertion in KnownAssignedXids" trying to apply backup. WAL contains the following record: rmgr: Standby     len (rec/tot):     98/    98, tx: 0, lsn: 1418/A9A76C90, prev 1418/A9A76C48, desc: RUNNING_XACTS nextXid 2004495309 latestCompletedXid 2004495307 oldestRunningXid 2004495290; 3 xacts: 2004495290 2004495308 2004495308 As you can notice, XID 2004495308 is encountered twice which cause error in KnownAssignedXidsAdd:     if (head > tail &&         TransactionIdFollowsOrEquals(KnownAssignedXids[head - 1], from_xid))     {         KnownAssignedXidsDisplay(LOG);         elog(ERROR, "out-of-order XID insertion in KnownAssignedXids");     } The probability of this error is very small but it can quite easily reproduced: you should just set breakpoint in debugger after calling MarkAsPrepared in twophase.c and then try to prepare any transaction. MarkAsPrepared  will add GXACT to proc array and at this moment there will be two entries in procarray with the same XID: (gdb) p procArray->numProcs $2 = 4 (gdb) p allPgXact[procArray->pgprocnos[0]] $4 = {xid = 513976717, xmin = 0, vacuumFlags = 0 '\000', overflowed = 0 '\000', delayChkpt = 1 '\001', nxids = 0 '\000',   used = 0 '\000', parent = 0x0} (gdb) p allPgXact[procArray->pgprocnos[1]] $5 = {xid = 0, xmin = 0, vacuumFlags = 0 '\000', overflowed = 0 '\000', delayChkpt = 0 '\000', nxids = 0 '\000',   used = 0 '\000', parent = 0x0} (gdb) p allPgXact[procArray->pgprocnos[2]] $6 = {xid = 0, xmin = 0, vacuumFlags = 0 '\000', overflowed = 0 '\000', delayChkpt = 0 '\000', nxids = 0 '\000',   used = 0 '\000', parent = 0x0} (gdb) p allPgXact[procArray->pgprocnos[3]] $7 = {xid = 513976717, xmin = 0, vacuumFlags = 0 '\000', overflowed = 0 '\000', delayChkpt = 0 '\000', nxids = 0 '\000',   used = 0 '\000', parent = 0x0} Then you should just wait for sometime until checkpoint timeout is triggered and it  logs snapshot: (gdb) bt #0  0x00000000007f3dab in GetRunningTransactionData () at procarray.c:2240 #1  0x00000000007fab22 in LogStandbySnapshot () at standby.c:943 #2  0x000000000077cde8 in BackgroundWriterMain () at bgwriter.c:331 #3  0x00000000005377f3 in AuxiliaryProcessMain (argc=2, argv=0x7ffe00aa00e0) at bootstrap.c:446 #4  0x000000000078e07e in StartChildProcess (type=BgWriterProcess) at postmaster.c:5323 #5  0x000000000078b6f0 in reaper (postgres_signal_arg=17) at postmaster.c:2948 #6  #7  0x00007f1356d665b3 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:84 #8  0x0000000000789931 in ServerLoop () at postmaster.c:1765 #9  0x000000000078906c in PostmasterMain (argc=3, argv=0x1902640) at postmaster.c:1406 #10 0x00000000006d0e4f in main (argc=3, argv=0x1902640) at main.c:228 Now generated RUNNING_XACTS record contains duplicated XIDs. I want to ask opinion of community about the best way of fixing this problem. Should we avoid storing duplicated XIDs in procarray (by invalidating XID in original pgaxct) or eliminate/change check for duplicate in KnownAssignedXidsAdd (for example just ignore duplicates)?