Re: [Proposal] Global temporary tables - Mailing list pgsql-hackers
From | wenjing |
---|---|
Subject | Re: [Proposal] Global temporary tables |
Date | |
Msg-id | CA+B_3V=djcOjqbLmzu7XFS-H_w91G61OzvWtt-=M4ffD+RRvEg@mail.gmail.com Whole thread Raw |
In response to | Re: [Proposal] Global temporary tables (Andrew Bille <andrewbille@gmail.com>) |
Responses |
Re: [Proposal] Global temporary tables
|
List | pgsql-hackers |
Andrew Bille <andrewbille@gmail.com> 于2021年10月20日周三 上午2:59写道:
Another thanks for the fix. It works for me.
But I found another crash!
This is a check code that was added this year, but it did find a problem and I fixed it.
Please review the new code(v57) again.
Wenjing
On master with the v56 patches applied:
initdb -D data
pg_ctl -w -t 5 -D data -l server.log start
echo "create global temp table t(i int4); insert into t values (1); vacuum t;" > tmp.sql
psql < tmp.sql
CREATE TABLE
INSERT 0 1
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
connection to server was lost
with following stack:
[New LWP 2192409]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: andrew regression [local] VACUUM '.
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: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007fb26b558859 in __GI_abort () at abort.c:79
#2 0x00005627ddd8466c in ExceptionalCondition (conditionName=conditionName@entry=0x5627dde153d0 "TransactionIdIsNormal(relfrozenxid)", errorType=errorType@entry=0x5627ddde100b "FailedAssertion", fileName=fileName@entry=0x5627dddfa697 "vacuum.c", lineNumber=lineNumber@entry=1170) at assert.c:69
#3 0x00005627dda70808 in vacuum_xid_failsafe_check (relfrozenxid=<optimized out>, relminmxid=<optimized out>) at vacuum.c:1170
#4 0x00005627dd8db7ee in lazy_check_wraparound_failsafe (vacrel=vacrel@entry=0x5627df5c9680) at vacuumlazy.c:2607
#5 0x00005627dd8ded18 in lazy_scan_heap (vacrel=vacrel@entry=0x5627df5c9680, params=params@entry=0x7fffb3d36100, aggressive=aggressive@entry=true) at vacuumlazy.c:978
#6 0x00005627dd8e019a in heap_vacuum_rel (rel=0x7fb26218af70, params=0x7fffb3d36100, bstrategy=<optimized out>) at vacuumlazy.c:644
#7 0x00005627dda70033 in table_relation_vacuum (bstrategy=<optimized out>, params=0x7fffb3d36100, rel=0x7fb26218af70) at ../../../src/include/access/tableam.h:1678
#8 vacuum_rel (relid=16385, relation=<optimized out>, params=params@entry=0x7fffb3d36100) at vacuum.c:2124
#9 0x00005627dda71624 in vacuum (relations=0x5627df610598, params=params@entry=0x7fffb3d36100, bstrategy=<optimized out>, bstrategy@entry=0x0, isTopLevel=isTopLevel@entry=true) at vacuum.c:476
#10 0x00005627dda71eb1 in ExecVacuum (pstate=pstate@entry=0x5627df567440, vacstmt=vacstmt@entry=0x5627df545e70, isTopLevel=isTopLevel@entry=true) at vacuum.c:269
#11 0x00005627ddc4a8cc in standard_ProcessUtility (pstmt=0x5627df5461c0, queryString=0x5627df545380 "vacuum t;", readOnlyTree=<optimized out>, context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x5627df5462b0, qc=0x7fffb3d36470) at utility.c:858
#12 0x00005627ddc4ada1 in ProcessUtility (pstmt=pstmt@entry=0x5627df5461c0, queryString=<optimized out>, readOnlyTree=<optimized out>, context=context@entry=PROCESS_UTILITY_TOPLEVEL, params=<optimized out>, queryEnv=<optimized out>, dest=0x5627df5462b0, qc=0x7fffb3d36470) at utility.c:527
#13 0x00005627ddc4822d in PortalRunUtility (portal=portal@entry=0x5627df5a67e0, pstmt=pstmt@entry=0x5627df5461c0, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false, dest=dest@entry=0x5627df5462b0, qc=qc@entry=0x7fffb3d36470) at pquery.c:1155
#14 0x00005627ddc48551 in PortalRunMulti (portal=portal@entry=0x5627df5a67e0, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false, dest=dest@entry=0x5627df5462b0, altdest=altdest@entry=0x5627df5462b0, qc=qc@entry=0x7fffb3d36470) at pquery.c:1312
#15 0x00005627ddc4896c in PortalRun (portal=portal@entry=0x5627df5a67e0, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true, dest=dest@entry=0x5627df5462b0, altdest=altdest@entry=0x5627df5462b0, qc=0x7fffb3d36470) at pquery.c:788
#16 0x00005627ddc44afb in exec_simple_query (query_string=query_string@entry=0x5627df545380 "vacuum t;") at postgres.c:1214
#17 0x00005627ddc469df in PostgresMain (dbname=<optimized out>, username=<optimized out>) at postgres.c:4497
#18 0x00005627ddb9fe7d in BackendRun (port=port@entry=0x5627df566580) at postmaster.c:4560
#19 0x00005627ddba3001 in BackendStartup (port=port@entry=0x5627df566580) at postmaster.c:4288
#20 0x00005627ddba3248 in ServerLoop () at postmaster.c:1801
#21 0x00005627ddba482a in PostmasterMain (argc=3, argv=<optimized out>) at postmaster.c:1473
#22 0x00005627ddae4d1d in main (argc=3, argv=0x5627df53f750) at main.c:198On Mon, Oct 18, 2021 at 7:00 PM wenjing <wjzeng2012@gmail.com> wrote:Hi AndrewI fixed the problem, please confirm again.ThanksWenjing
Attachment
pgsql-hackers by date: