Re: [Proposal] Global temporary tables

From: wenjing <wjzeng2012(at)gmail(dot)com>
To: Andrew Bille <andrewbille(at)gmail(dot)com>
Cc: wenjing <wenjing(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tony Zhu <tony(dot)zhu(at)ww-it(dot)cn>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [Proposal] Global temporary tables
Date: 2021-10-21 09:25:31
Message-ID: CA+B_3V=djcOjqbLmzu7XFS-H_w91G61OzvWtt-=M4ffD+RRvEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Bille <andrewbille(at)gmail(dot)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(at)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(at)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(at)entry=0x5627dde153d0
> "TransactionIdIsNormal(relfrozenxid)", errorType=errorType(at)entry=0x5627ddde100b
> "FailedAssertion", fileName=fileName(at)entry=0x5627dddfa697 "vacuum.c",
> lineNumber=lineNumber(at)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(at)entry=0x5627df5c9680) at vacuumlazy.c:2607
> #5 0x00005627dd8ded18 in lazy_scan_heap (vacrel=vacrel(at)entry=0x5627df5c9680,
> params=params(at)entry=0x7fffb3d36100, aggressive=aggressive(at)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(at)entry=0x7fffb3d36100)
> at vacuum.c:2124
> #9 0x00005627dda71624 in vacuum (relations=0x5627df610598,
> params=params(at)entry=0x7fffb3d36100, bstrategy=<optimized out>,
> bstrategy(at)entry=0x0, isTopLevel=isTopLevel(at)entry=true) at vacuum.c:476
> #10 0x00005627dda71eb1 in ExecVacuum (pstate=pstate(at)entry=0x5627df567440,
> vacstmt=vacstmt(at)entry=0x5627df545e70, isTopLevel=isTopLevel(at)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(at)entry=0x5627df5461c0,
> queryString=<optimized out>, readOnlyTree=<optimized out>,
> context=context(at)entry=PROCESS_UTILITY_TOPLEVEL, params=<optimized out>,
> queryEnv=<optimized out>, dest=0x5627df5462b0, qc=0x7fffb3d36470) at
> utility.c:527
> #13 0x00005627ddc4822d in PortalRunUtility (portal=portal(at)entry=0x5627df5a67e0,
> pstmt=pstmt(at)entry=0x5627df5461c0, isTopLevel=isTopLevel(at)entry=true,
> setHoldSnapshot=setHoldSnapshot(at)entry=false, dest=dest(at)entry=0x5627df5462b0,
> qc=qc(at)entry=0x7fffb3d36470) at pquery.c:1155
> #14 0x00005627ddc48551 in PortalRunMulti (portal=portal(at)entry=0x5627df5a67e0,
> isTopLevel=isTopLevel(at)entry=true, setHoldSnapshot=setHoldSnapshot(at)entry=false,
> dest=dest(at)entry=0x5627df5462b0, altdest=altdest(at)entry=0x5627df5462b0,
> qc=qc(at)entry=0x7fffb3d36470) at pquery.c:1312
> #15 0x00005627ddc4896c in PortalRun (portal=portal(at)entry=0x5627df5a67e0,
> count=count(at)entry=9223372036854775807, isTopLevel=isTopLevel(at)entry=true,
> run_once=run_once(at)entry=true, dest=dest(at)entry=0x5627df5462b0,
> altdest=altdest(at)entry=0x5627df5462b0, qc=0x7fffb3d36470) at pquery.c:788
> #16 0x00005627ddc44afb in exec_simple_query
> (query_string=query_string(at)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(at)entry=0x5627df566580) at
> postmaster.c:4560
> #19 0x00005627ddba3001 in BackendStartup (port=port(at)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:198
>
> On Mon, Oct 18, 2021 at 7:00 PM wenjing <wjzeng2012(at)gmail(dot)com> wrote:
>
>> Hi Andrew
>> I fixed the problem, please confirm again.
>> Thanks
>>
>> Wenjing
>>
>

Attachment Content-Type Size
0002-gtt-v57-doc.patch application/octet-stream 7.5 KB
0001-gtt-v57-reademe.patch application/octet-stream 7.5 KB
0004-gtt-v57-regress.patch application/octet-stream 79.4 KB
0003-gtt-v57-implementation.patch application/octet-stream 169.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-10-21 09:45:35 Re: Data is copied twice when specifying both child and parent table in publication
Previous Message Amit Kapila 2021-10-21 08:42:10 Re: relation OID in ReorderBufferToastReplace error message