Thread
Commits
-
Check for relation length overrun soon enough.
- cc4de2bba02f 9.6.24 landed
- ca1dd6234049 10.19 landed
- a7a73ce30171 12.9 landed
- 8481f99896a1 15.0 landed
- 7430c774209c 14.0 landed
- 1a23b669db57 11.14 landed
- 04118de78fe9 13.5 landed
-
trap instead of error on 32 TiB table
Christoph Berg <christoph.berg@credativ.de> — 2021-09-09T11:52:41Z
I was wondering what happens when the 32 TiB per table limit is reached, so I faked 32767 1 GiB sparse files using dd and then tried inserting more rows. On a cassert-enabled build I got: TRAP: FailedAssertion("tagPtr->blockNum != P_NEW", File: "./build/../src/backend/storage/buffer/buf_table.c", Line: 125) On a normal build, I got: ERROR: cannot extend file "base/18635/53332" beyond 4294967295 blocks ORT: mdextend, md.c:443 Shouldn't the cassert build raise the ERROR instead as well? PostgreSQL 13.4. Christoph -- Senior Consultant, Tel.: +49 2166 9901 187 credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Sascha Heuer, Geoff Richardson, Peter Lilley; Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz -
Re: trap instead of error on 32 TiB table
Robert Haas <robertmhaas@gmail.com> — 2021-09-09T13:30:57Z
On Thu, Sep 9, 2021 at 7:52 AM Christoph Berg <christoph.berg@credativ.de> wrote: > Shouldn't the cassert build raise the ERROR instead as well? We should definitely get an ERROR in both cases, not an assertion failure. Exactly which ERROR we get seems negotiable. -- Robert Haas EDB: http://www.enterprisedb.com
-
Re: trap instead of error on 32 TiB table
Tom Lane <tgl@sss.pgh.pa.us> — 2021-09-09T13:44:55Z
Christoph Berg <christoph.berg@credativ.de> writes: > I was wondering what happens when the 32 TiB per table limit is > reached, so I faked 32767 1 GiB sparse files using dd and then tried > inserting more rows. > On a cassert-enabled build I got: > TRAP: FailedAssertion("tagPtr->blockNum != P_NEW", File: "./build/../src/backend/storage/buffer/buf_table.c", Line: 125) Can you provide a stack trace from that? (or else a recipe for reproducing the bug ... I'm not excited about reverse-engineering the details of the method) regards, tom lane -
Re: trap instead of error on 32 TiB table
Christoph Berg <christoph.berg@credativ.de> — 2021-09-09T14:04:29Z
Re: Tom Lane > Can you provide a stack trace from that? PG log: TRAP: FailedAssertion("tagPtr->blockNum != P_NEW", File: "./build/../src/backend/storage/buffer/buf_table.c", Line: 125) postgres: 13/main: cbe postgres [local] INSERT(ExceptionalCondition+0x7d)[0x558b6223d44d] postgres: 13/main: cbe postgres [local] INSERT(BufTableInsert+0x89)[0x558b620bafb9] postgres: 13/main: cbe postgres [local] INSERT(+0x441827)[0x558b620bf827] postgres: 13/main: cbe postgres [local] INSERT(ReadBufferExtended+0x7a)[0x558b620c021a] postgres: 13/main: cbe postgres [local] INSERT(RelationGetBufferForTuple+0x250)[0x558b61da7850] postgres: 13/main: cbe postgres [local] INSERT(heap_insert+0x8b)[0x558b61d965cb] postgres: 13/main: cbe postgres [local] INSERT(+0x123b89)[0x558b61da1b89] postgres: 13/main: cbe postgres [local] INSERT(+0x30294c)[0x558b61f8094c] postgres: 13/main: cbe postgres [local] INSERT(+0x303660)[0x558b61f81660] postgres: 13/main: cbe postgres [local] INSERT(standard_ExecutorRun+0x115)[0x558b61f4eaa5] postgres: 13/main: cbe postgres [local] INSERT(+0x47fb72)[0x558b620fdb72] postgres: 13/main: cbe postgres [local] INSERT(+0x4809be)[0x558b620fe9be] postgres: 13/main: cbe postgres [local] INSERT(PortalRun+0x1c2)[0x558b620fee72] postgres: 13/main: cbe postgres [local] INSERT(+0x47c2e0)[0x558b620fa2e0] postgres: 13/main: cbe postgres [local] INSERT(PostgresMain+0x1a53)[0x558b620fc153] postgres: 13/main: cbe postgres [local] INSERT(+0x3e7f74)[0x558b62065f74] postgres: 13/main: cbe postgres [local] INSERT(PostmasterMain+0xd78)[0x558b62066e68] postgres: 13/main: cbe postgres [local] INSERT(main+0x796)[0x558b61d40356] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f57071fad0a] postgres: 13/main: cbe postgres [local] INSERT(_start+0x2a)[0x558b61d403fa] 2021-09-09 13:19:31.024 CEST [1533530] LOG: server process (PID 1534108) was terminated by signal 6: Aborted 2021-09-09 13:19:31.024 CEST [1533530] DETAIL: Failed process was running: insert into huge select generate_series(1,10); gdb bt: Core was generated by `postgres: 13/main: cbe postgres [local] INSERT '. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007f57071f9537 in __GI_abort () at abort.c:79 #2 0x0000558b6223d46e in ExceptionalCondition (conditionName=conditionName@entry=0x558b623b2577 "tagPtr->blockNum != P_NEW", errorType=errorType@entry=0x558b6229b016 "FailedAssertion", fileName=fileName@entry=0x558b623b2598 "./build/../src/backend/storage/buffer/buf_table.c", lineNumber=lineNumber@entry=125) at ./build/../src/backend/utils/error/assert.c:67 #3 0x0000558b620bafb9 in BufTableInsert (tagPtr=tagPtr@entry=0x7ffec8919330, hashcode=hashcode@entry=960067002, buf_id=<optimized out>) at ./build/../src/backend/storage/buffer/buf_table.c:125 #4 0x0000558b620bf827 in BufferAlloc (foundPtr=0x7ffec891932b, strategy=0x0, blockNum=4294967295, forkNum=MAIN_FORKNUM, relpersistence=112 'p', smgr=0x558b62ed4b38) at ./build/../src/backend/storage/buffer/bufmgr.c:1234 #5 ReadBuffer_common (smgr=0x558b62ed4b38, relpersistence=<optimized out>, forkNum=forkNum@entry=MAIN_FORKNUM, blockNum=blockNum@entry=4294967295, mode=mode@entry=RBM_ZERO_AND_LOCK, strategy=0x0, hit=0x7ffec89193d7) at ./build/../src/backend/storage/buffer/bufmgr.c:761 #6 0x0000558b620c021a in ReadBufferExtended (reln=0x7f56fb4f8120, forkNum=forkNum@entry=MAIN_FORKNUM, blockNum=blockNum@entry=4294967295, mode=mode@entry=RBM_ZERO_AND_LOCK, strategy=strategy@entry=0x0) at ./build/../src/backend/storage/buffer/bufmgr.c:677 #7 0x0000558b61da7056 in ReadBufferBI (relation=relation@entry=0x7f56fb4f8120, targetBlock=targetBlock@entry=4294967295, mode=mode@entry=RBM_ZERO_AND_LOCK, bistate=bistate@entry=0x0) at ./build/../src/backend/access/heap/hio.c:87 #8 0x0000558b61da7850 in RelationGetBufferForTuple (relation=relation@entry=0x7f56fb4f8120, len=32, otherBuffer=otherBuffer@entry=0, options=options@entry=0, bistate=bistate@entry=0x0, vmbuffer=vmbuffer@entry=0x7ffec89194c8, vmbuffer_other=0x0) at ./build/../src/backend/access/heap/hio.c:598 #9 0x0000558b61d965cb in heap_insert (relation=relation@entry=0x7f56fb4f8120, tup=tup@entry=0x558b62f0b780, cid=cid@entry=0, options=options@entry=0, bistate=bistate@entry=0x0) at ./build/../src/backend/access/heap/heapam.c:1868 #10 0x0000558b61da1b89 in heapam_tuple_insert (relation=0x7f56fb4f8120, slot=0x558b62f0b6b0, cid=0, options=0, bistate=0x0) at ./build/../src/backend/access/heap/heapam_handler.c:251 #11 0x0000558b61f8094c in table_tuple_insert (bistate=0x0, options=0, cid=<optimized out>, slot=0x558b62f0b6b0, rel=0x7f56fb4f8120) at ./build/../src/include/access/tableam.h:1156 #12 ExecInsert (mtstate=0x558b62f0ab50, slot=0x558b62f0b6b0, planSlot=0x558b62f0b6b0, srcSlot=0x0, returningRelInfo=0x558b62f0aa38, estate=0x558b62f0a7c0, canSetTag=true) at ./build/../src/backend/executor/nodeModifyTable.c:642 #13 0x0000558b61f81660 in ExecModifyTable (pstate=0x558b62f0ab50) at ./build/../src/backend/executor/nodeModifyTable.c:2321 #14 0x0000558b61f4eaa5 in ExecProcNode (node=0x558b62f0ab50) at ./build/../src/include/executor/executor.h:248 #15 ExecutePlan (execute_once=<optimized out>, dest=0x558b62e6d908, direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>, operation=CMD_INSERT, use_parallel_mode=<optimized out>, planstate=0x558b62f0ab50, estate=0x558b62f0a7c0) at ./build/../src/backend/executor/execMain.c:1632 #16 standard_ExecutorRun (queryDesc=0x558b62e68920, direction=<optimized out>, count=0, execute_once=<optimized out>) at ./build/../src/backend/executor/execMain.c:350 #17 0x0000558b620fdb72 in ProcessQuery (plan=0x558b62e6d798, sourceText=0x558b62e22000 "insert into huge values ('boom');", params=0x0, queryEnv=0x0, dest=0x558b62e6d908, qc=0x7ffec8919a00) at ./build/../src/backend/tcop/pquery.c:160 #18 0x0000558b620fe9be in PortalRunMulti (portal=portal@entry=0x558b62eade60, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false, dest=dest@entry=0x558b62e6d908, altdest=altdest@entry=0x558b62e6d908, qc=qc@entry=0x7ffec8919a00) at ./build/../src/backend/tcop/pquery.c:1263 #19 0x0000558b620fee72 in PortalRun (portal=portal@entry=0x558b62eade60, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true, dest=dest@entry=0x558b62e6d908, altdest=altdest@entry=0x558b62e6d908, qc=0x7ffec8919a00) at ./build/../src/backend/tcop/pquery.c:786 #20 0x0000558b620fa2e0 in exec_simple_query (query_string=0x558b62e22000 "insert into huge values ('boom');") at ./build/../src/backend/tcop/postgres.c:1239 #21 0x0000558b620fc153 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x558b62e71f90, dbname=<optimized out>, username=<optimized out>) at ./build/../src/backend/tcop/postgres.c:4339 #22 0x0000558b62065f74 in BackendRun (port=0x558b62e6b360) at ./build/../src/backend/postmaster/postmaster.c:4526 #23 BackendStartup (port=0x558b62e6b360) at ./build/../src/backend/postmaster/postmaster.c:4210 #24 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1739 #25 0x0000558b62066e68 in PostmasterMain (argc=argc@entry=5, argv=argv@entry=0x558b62e1ae80) at ./build/../src/backend/postmaster/postmaster.c:1412 #26 0x0000558b61d40356 in main (argc=5, argv=0x558b62e1ae80) at ./build/../src/backend/main/main.c:210 (Both should be from the same instance.) > (or else a recipe for reproducing the bug ... I'm not excited > about reverse-engineering the details of the method) Create a table, note the relfilenode, shut down PG, and fn=53332 dd if=/dev/zero bs=8k of=$fn seek=131071 count=1 for i in {1..32766}; do dd if=/dev/zero bs=8k of=$fn.$i seek=131071 count=1; done dd if=/dev/zero bs=8k of=$fn.32767 seek=131070 count=1 rm ${fn}_fsm ... and then start PG and insert enough to fill the last block. Christoph -- Senior Consultant, Tel.: +49 2166 9901 187 credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Sascha Heuer, Geoff Richardson, Peter Lilley; Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz -
Re: trap instead of error on 32 TiB table
Tom Lane <tgl@sss.pgh.pa.us> — 2021-09-09T14:25:27Z
Christoph Berg <christoph.berg@credativ.de> writes: >> Can you provide a stack trace from that? > #2 0x0000558b6223d46e in ExceptionalCondition (conditionName=conditionName@entry=0x558b623b2577 "tagPtr->blockNum != P_NEW", > errorType=errorType@entry=0x558b6229b016 "FailedAssertion", > fileName=fileName@entry=0x558b623b2598 "./build/../src/backend/storage/buffer/buf_table.c", lineNumber=lineNumber@entry=125) > at ./build/../src/backend/utils/error/assert.c:67 > #3 0x0000558b620bafb9 in BufTableInsert (tagPtr=tagPtr@entry=0x7ffec8919330, hashcode=hashcode@entry=960067002, buf_id=<optimized out>) > at ./build/../src/backend/storage/buffer/buf_table.c:125 > #4 0x0000558b620bf827 in BufferAlloc (foundPtr=0x7ffec891932b, strategy=0x0, blockNum=4294967295, forkNum=MAIN_FORKNUM, > relpersistence=112 'p', smgr=0x558b62ed4b38) at ./build/../src/backend/storage/buffer/bufmgr.c:1234 Ah, thanks. I don't think it's unreasonable for BufTableInsert to contain that assertion --- we shouldn't be trying to allocate a buffer for an illegal block number. The regular error comes from mdextend, but that is too late under this worldview, because smgrextend expects to be given a zero-filled buffer to write out. I think where we ought to be making the check is right where ReadBuffer_common replaces P_NEW: /* Substitute proper block number if caller asked for P_NEW */ if (isExtend) + { blockNum = smgrnblocks(smgr, forkNum); + if (blockNum == InvalidBlockNumber) + ereport(ERROR, + (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED), + errmsg("cannot extend file \"%s\" beyond %u blocks", + relpath(smgr->smgr_rnode, forkNum), + InvalidBlockNumber))); + } Having done that, the check in md.c could be reduced to an Assert, although there's something to be said for leaving it as-is as an extra layer of defense. regards, tom lane -
Re: trap instead of error on 32 TiB table
Heikki Linnakangas <hlinnaka@iki.fi> — 2021-09-09T19:54:32Z
On 09/09/2021 17:25, Tom Lane wrote: > Having done that, the check in md.c could be reduced to an Assert, > although there's something to be said for leaving it as-is as an > extra layer of defense. Some operations call smgrextend() directly, like B-tree index creation. We don't want those operations to hit an assertion either. - Heikki
-
The End of the WAL
Christoph Berg <christoph.berg@credativ.de> — 2021-09-10T10:06:33Z
Re: Heikki Linnakangas > On 09/09/2021 17:25, Tom Lane wrote: > > Having done that, the check in md.c could be reduced to an Assert, > > although there's something to be said for leaving it as-is as an > > extra layer of defense. > > Some operations call smgrextend() directly, like B-tree index creation. We > don't want those operations to hit an assertion either. Thanks, I can now see a proper error on 15devel with cassert enabled: # insert into huge select generate_series(1,1000); FEHLER: 54000: cannot extend relation base/13550/16384 beyond 4294967295 blocks ORT: ReadBuffer_common, bufmgr.c:831 Some months ago I had already tried what happens on running into another limit, namely the end of WAL. Back then I was attributing the result to "won't happen anyway", but since we are talking asserts, there is the result: /usr/lib/postgresql/15/bin/pg_resetwal -l 00000001FFFFFFFF000000FF -D $PWD select pg_current_wal_lsn(); pg_current_wal_lsn ──────────────────── FFFFFFFF/FF000150 create table foo (id bigint); repeat a few times: insert into foo select generate_series(1,200000); 15devel, cassert: TRAP: FailedAssertion("XLogRecPtrToBytePos(*EndPos) == endbytepos", File: "./build/../src/backend/access/transam/xlog.c", Line: 1324, PID: 1651661) postgres: 15/regress: cbe postgres ::1(45564) INSERT(ExceptionalCondition+0x9a)[0x564ad15461ba] postgres: 15/regress: cbe postgres ::1(45564) INSERT(+0x223022)[0x564ad115f022] postgres: 15/regress: cbe postgres ::1(45564) INSERT(XLogInsert+0x653)[0x564ad116adf3] postgres: 15/regress: cbe postgres ::1(45564) INSERT(heap_insert+0x3ae)[0x564ad10f0a2e] postgres: 15/regress: cbe postgres ::1(45564) INSERT(+0x1bf8e9)[0x564ad10fb8e9] postgres: 15/regress: cbe postgres ::1(45564) INSERT(+0x35e30c)[0x564ad129a30c] postgres: 15/regress: cbe postgres ::1(45564) INSERT(+0x35eedc)[0x564ad129aedc] postgres: 15/regress: cbe postgres ::1(45564) INSERT(standard_ExecutorRun+0x115)[0x564ad12695b5] postgres: 15/regress: cbe postgres ::1(45564) INSERT(+0x4da312)[0x564ad1416312] postgres: 15/regress: cbe postgres ::1(45564) INSERT(+0x4db0ee)[0x564ad14170ee] postgres: 15/regress: cbe postgres ::1(45564) INSERT(PortalRun+0x2ec)[0x564ad14176bc] postgres: 15/regress: cbe postgres ::1(45564) INSERT(+0x4d72b6)[0x564ad14132b6] postgres: 15/regress: cbe postgres ::1(45564) INSERT(PostgresMain+0x181c)[0x564ad1414edc] postgres: 15/regress: cbe postgres ::1(45564) INSERT(+0x43fd80)[0x564ad137bd80] postgres: 15/regress: cbe postgres ::1(45564) INSERT(PostmasterMain+0xca0)[0x564ad137cd10] postgres: 15/regress: cbe postgres ::1(45564) INSERT(main+0x221)[0x564ad10973d1] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f63bcbe1d0a] postgres: 15/regress: cbe postgres ::1(45564) INSERT(_start+0x2a)[0x564ad10979ca] 2021-09-10 11:44:40.997 CEST [1651617] LOG: request to flush past end of generated WAL; request FFFFFFFF/FFFFE000, current position 0/50 2021-09-10 11:44:42.019 CEST [1651613] LOG: Serverprozess (PID 1651661) wurde von Signal 6 beendet: Abgebrochen 2021-09-10 11:44:42.019 CEST [1651613] DETAIL: Der fehlgeschlagene Prozess führte aus: insert into foo select generate_series(1,200000); The system properly (?) recovers, resuming at some FFFFFFFF/FFE614B8 position (i.e. discarding the part that was overflowing). However, if I push it by moving closer to the end by doing smaller inserts, I can get it into an infinite recovery loop: 2021-09-10 11:48:41.050 CEST [1652403] LOG: Datenbanksystem wurde beim Herunterfahren unterbrochen; letzte bekannte Aktion am 2021-09-10 11:48:40 CEST 2021-09-10 11:48:41.051 CEST [1652403] LOG: Datenbanksystem wurde nicht richtig heruntergefahren; automatische Wiederherstellung läuft 2021-09-10 11:48:41.051 CEST [1652403] LOG: Redo beginnt bei FFFFFFFF/FFFFDF78 2021-09-10 11:48:41.051 CEST [1652403] LOG: ungültige Datensatzlänge bei FFFFFFFF/FFFFDFB0: 24 erwartet, 0 erhalten 2021-09-10 11:48:41.051 CEST [1652403] LOG: redo done at FFFFFFFF/FFFFDF78 system usage: CPU: Benutzer: 0,00 s, System: 0,00 s, verstrichen: 0,00 s TRAP: FailedAssertion("((XLogPageHeader) cachedPos)->xlp_magic == XLOG_PAGE_MAGIC", File: "./build/../src/backend/access/transam/xlog.c", Line: 1982, PID: 1652404) postgres: 15/regress: checkpointer performing end-of-recovery checkpoint(ExceptionalCondition+0x9a)[0x564ad15461ba] postgres: 15/regress: checkpointer performing end-of-recovery checkpoint(+0x2221e8)[0x564ad115e1e8] postgres: 15/regress: checkpointer performing end-of-recovery checkpoint(XLogInsertRecord+0x587)[0x564ad115ea27] postgres: 15/regress: checkpointer performing end-of-recovery checkpoint(XLogInsert+0x653)[0x564ad116adf3] postgres: 15/regress: checkpointer performing end-of-recovery checkpoint(CreateCheckPoint+0x64e)[0x564ad11608ee] postgres: 15/regress: checkpointer performing end-of-recovery checkpoint(CheckpointerMain+0x3d4)[0x564ad136db34] postgres: 15/regress: checkpointer performing end-of-recovery checkpoint(AuxiliaryProcessMain+0xef)[0x564ad136bacf] postgres: 15/regress: checkpointer performing end-of-recovery checkpoint(+0x43d116)[0x564ad1379116] postgres: 15/regress: checkpointer performing end-of-recovery checkpoint(+0x43f71a)[0x564ad137b71a] postgres: 15/regress: checkpointer performing end-of-recovery checkpoint(PostmasterMain+0xca0)[0x564ad137cd10] postgres: 15/regress: checkpointer performing end-of-recovery checkpoint(main+0x221)[0x564ad10973d1] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f63bcbe1d0a] postgres: 15/regress: checkpointer performing end-of-recovery checkpoint(_start+0x2a)[0x564ad10979ca] 2021-09-10 11:48:41.791 CEST [1651613] LOG: Checkpointer-Prozess (PID 1652404) wurde von Signal 6 beendet: Abgebrochen 2021-09-10 11:48:41.791 CEST [1651613] LOG: aktive Serverprozesse werden abgebrochen 2021-09-10 11:48:41.791 CEST [1651613] LOG: alle Serverprozesse beendet; initialisiere neu ... goto 10 Doing the same test on 15devel without cassert, the inserting query gets stuck in a busy loop (no wait_event) that ^C won't terminate. Two backtraces from that running process: (gdb) bt #0 0x0000563604fdb63b in memset (__len=8192, __ch=0, __dest=0x7f710f9b6000) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:71 #1 AdvanceXLInsertBuffer (upto=upto@entry=18446744073709543424, opportunistic=opportunistic@entry=false) at ./build/../src/backend/access/transam/xlog.c:2220 #2 0x0000563604fdb920 in GetXLogBuffer (ptr=18446744073709543424) at ./build/../src/backend/access/transam/xlog.c:1959 #3 0x0000563604fdd1b1 in CopyXLogRecordToWAL (EndPos=18446744073709543480, StartPos=18446744073709543392, rdata=0x56360562b1c0 <hdr_rdt>, isLogSwitch=false, write_len=63) at ./build/../src/backend/access/transam/xlog.c:1558 #4 XLogInsertRecord (rdata=rdata@entry=0x56360562b1c0 <hdr_rdt>, fpw_lsn=fpw_lsn@entry=18446744073709543392, flags=<optimized out>, num_fpi=num_fpi@entry=0) at ./build/../src/backend/access/transam/xlog.c:1123 #5 0x0000563604fe774a in XLogInsert (rmid=rmid@entry=10 '\n', info=info@entry=0 '\000') at ./build/../src/backend/access/transam/xloginsert.c:480 #6 0x0000563604f87b27 in heap_insert (relation=relation@entry=0x7f710f6d7938, tup=tup@entry=0x5636061bc288, cid=cid@entry=0, options=options@entry=0, bistate=bistate@entry=0x0) at ./build/../src/backend/access/heap/heapam.c:2208 #7 0x0000563604f8fe89 in heapam_tuple_insert (relation=0x7f710f6d7938, slot=0x5636061bc1f8, cid=0, options=0, bistate=0x0) at ./build/../src/backend/access/heap/heapam_handler.c:252 #8 0x00005636050ff35c in table_tuple_insert (bistate=0x0, options=0, cid=<optimized out>, slot=0x5636061bc1f8, rel=<optimized out>) at ./build/../src/include/access/tableam.h:1374 #9 ExecInsert (mtstate=0x5636061a5ad8, resultRelInfo=0x5636061a5ce8, slot=0x5636061bc1f8, planSlot=0x5636061bb778, estate=0x5636061a5868, canSetTag=<optimized out>) at ./build/../src/backend/executor/nodeModifyTable.c:934 #10 0x00005636051004c7 in ExecModifyTable (pstate=<optimized out>) at ./build/../src/backend/executor/nodeModifyTable.c:2561 #11 0x00005636050d599d in ExecProcNode (node=0x5636061a5ad8) at ./build/../src/include/executor/executor.h:257 #12 ExecutePlan (execute_once=<optimized out>, dest=0x5636061b22f8, direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>, operation=CMD_INSERT, use_parallel_mode=<optimized out>, planstate=0x5636061a5ad8, estate=0x5636061a5868) at ./build/../src/backend/executor/execMain.c:1551 #13 standard_ExecutorRun (queryDesc=0x563606109d08, direction=<optimized out>, count=0, execute_once=<optimized out>) at ./build/../src/backend/executor/execMain.c:361 #14 0x00005636052501e2 in ProcessQuery (plan=0x5636061b2218, sourceText=0x5636060e7128 "insert into foo select generate_series(1,500000);", params=0x0, queryEnv=0x0, dest=0x5636061b22f8, qc=0x7ffdbe808cc0) at ./build/../src/backend/tcop/pquery.c:160 #15 0x0000563605250dd9 in PortalRunMulti (portal=portal@entry=0x56360614b3a8, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false, dest=dest@entry=0x5636061b22f8, altdest=altdest@entry=0x5636061b22f8, qc=qc@entry=0x7ffdbe808cc0) at ./build/../src/backend/tcop/pquery.c:1266 #16 0x000056360525129c in PortalRun (portal=portal@entry=0x56360614b3a8, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true, dest=dest@entry=0x5636061b22f8, altdest=altdest@entry=0x5636061b22f8, qc=0x7ffdbe808cc0) at ./build/../src/backend/tcop/pquery.c:786 #17 0x000056360524d2dd in exec_simple_query (query_string=0x5636060e7128 "insert into foo select generate_series(1,500000);") at ./build/../src/backend/tcop/postgres.c:1214 #18 0x000056360524f20f in PostgresMain (argc=argc@entry=1, argv=argv@entry=0x7ffdbe809190, dbname=<optimized out>, username=<optimized out>) at ./build/../src/backend/tcop/postgres.c:4488 #19 0x00005636051cc178 in BackendRun (port=<optimized out>, port=<optimized out>) at ./build/../src/backend/postmaster/postmaster.c:4521 #20 BackendStartup (port=<optimized out>) at ./build/../src/backend/postmaster/postmaster.c:4243 #21 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1765 #22 0x00005636051cd000 in PostmasterMain (argc=argc@entry=5, argv=argv@entry=0x5636060e1ea0) at ./build/../src/backend/postmaster/postmaster.c:1437 #23 0x0000563604f457f1 in main (argc=5, argv=0x5636060e1ea0) at ./build/../src/backend/main/main.c:199 (gdb) bt #0 0x0000563604fdb6cf in AdvanceXLInsertBuffer (upto=upto@entry=18446744073709543424, opportunistic=opportunistic@entry=false) at ./build/../src/backend/access/transam/xlog.c:2147 #1 0x0000563604fdb920 in GetXLogBuffer (ptr=18446744073709543424) at ./build/../src/backend/access/transam/xlog.c:1959 #2 0x0000563604fdd1b1 in CopyXLogRecordToWAL (EndPos=18446744073709543480, StartPos=18446744073709543392, rdata=0x56360562b1c0 <hdr_rdt>, isLogSwitch=false, write_len=63) at ./build/../src/backend/access/transam/xlog.c:1558 #3 XLogInsertRecord (rdata=rdata@entry=0x56360562b1c0 <hdr_rdt>, fpw_lsn=fpw_lsn@entry=18446744073709543392, flags=<optimized out>, num_fpi=num_fpi@entry=0) at ./build/../src/backend/access/transam/xlog.c:1123 #4 0x0000563604fe774a in XLogInsert (rmid=rmid@entry=10 '\n', info=info@entry=0 '\000') at ./build/../src/backend/access/transam/xloginsert.c:480 #5 0x0000563604f87b27 in heap_insert (relation=relation@entry=0x7f710f6d7938, tup=tup@entry=0x5636061bc288, cid=cid@entry=0, options=options@entry=0, bistate=bistate@entry=0x0) at ./build/../src/backend/access/heap/heapam.c:2208 ... Christoph -- Senior Consultant, Tel.: +49 2166 9901 187 credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Sascha Heuer, Geoff Richardson, Peter Lilley; Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz