Horton

Re: [Proposal] Global temporary tables

Wenjing Zeng <wjzeng2012@gmail.com>

View thread
From: wenjing <wjzeng2012@gmail.com>
To: Andrew Bille <andrewbille@gmail.com>
Cc: wenjing <wenjing@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, Tony Zhu <tony.zhu@ww-it.cn>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-10-21T09:25:31Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. PageAddItemExtended(): Add LP_UNUSED assertion.

  2. Remove temporary files after backend crash

  3. Fix comment in indexing.c

  4. Fix failure to ignore leftover temp tables after a server crash.

Attachments

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:198
>
> On Mon, Oct 18, 2021 at 7:00 PM wenjing <wjzeng2012@gmail.com> wrote:
>
>> Hi Andrew
>> I fixed the problem, please confirm again.
>> Thanks
>>
>> Wenjing
>>
>