Re: [Proposal] Global temporary tables

wenjing <wjzeng2012@gmail.com> 于2021年10月30日周六 上午1:28写道：

>
>
> Andrew Bille <andrewbille@gmail.com> 于2021年10月28日周四 下午6:30写道：
>
>> Thanks, the "group by" is fixed
>>
>> Yet another crash (on v58 patches), reproduced with:
>>
>> psql -t -c "create global temp table t(b text)
>> with(on_commit_delete_rows=true); create index idx_b on t (b); insert into
>> t values('test'); alter table t alter b type varchar;"
>> server closed the connection unexpectedly
>>         This probably means the server terminated abnormally
>>         before or while processing the request.
>> connection to server was lost
>>
> Thank you for pointing that out.
> This is due to an optimization point: ALTER Table reuses the relfilenode
> of the old index.
> I have banned this optimization point for GTT, I am not entirely sure it
> is appropriate, maybe you can give some suggestions.
> Please review the new code(v59).
>
>
> Wenjing
>
>
>
>>
>> with trace:
>>
>> [New LWP 569199]
>> [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 postgres [local] ALTER TABLE
>>                             '.
>> 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  0x00007f197493f859 in __GI_abort () at abort.c:79
>> #2  0x00005562b3306fb9 in ExceptionalCondition
>> (conditionName=0x5562b34dd740 "reln->md_num_open_segs[forkNum] == 0",
>> errorType=0x5562b34dd72c "FailedAssertion", fileName=0x5562b34dd727 "md.c",
>> lineNumber=187) at assert.c:69
>> #3  0x00005562b3148f15 in mdcreate (reln=0x5562b41abdc0,
>> forkNum=MAIN_FORKNUM, isRedo=false) at md.c:187
>> #4  0x00005562b314b73f in smgrcreate (reln=0x5562b41abdc0,
>> forknum=MAIN_FORKNUM, isRedo=false) at smgr.c:335
>> #5  0x00005562b2d88b23 in RelationCreateStorage (rnode=...,
>> relpersistence=103 'g', rel=0x7f196b597270) at storage.c:154
>> #6  0x00005562b2d5a408 in index_build (heapRelation=0x7f196b58dc40,
>> indexRelation=0x7f196b597270, indexInfo=0x5562b4167d60, isreindex=true,
>> parallel=false) at index.c:3038
>> #7  0x00005562b2d533c1 in RelationTruncateIndexes
>> (heapRelation=0x7f196b58dc40, lockmode=1) at heap.c:3354
>> #8  0x00005562b2d5360b in heap_truncate_one_rel (rel=0x7f196b58dc40) at
>> heap.c:3452
>> #9  0x00005562b2d53544 in heap_truncate (relids=0x5562b4167c58,
>> is_global_temp=true) at heap.c:3410
>> #10 0x00005562b2ea09fc in PreCommit_on_commit_actions () at
>> tablecmds.c:16495
>> #11 0x00005562b2d0d4ee in CommitTransaction () at xact.c:2140
>> #12 0x00005562b2d0e320 in CommitTransactionCommand () at xact.c:2979
>> #13 0x00005562b3151b7e in finish_xact_command () at postgres.c:2721
>> #14 0x00005562b314f340 in exec_simple_query (query_string=0x5562b40c2170
>> "create global temp table t(b text) with(on_commit_delete_rows=true);
>> create index idx_b on t (b); insert into t values('test'); alter table t
>> alter b type varchar;") at postgres.c:1239
>> #15 0x00005562b3153f0a in PostgresMain (dbname=0x5562b40ed6e8 "postgres",
>> username=0x5562b40ed6c8 "andrew") at postgres.c:4497
>> #16 0x00005562b307df6e in BackendRun (port=0x5562b40e4500) at
>> postmaster.c:4560
>> #17 0x00005562b307d853 in BackendStartup (port=0x5562b40e4500) at
>> postmaster.c:4288
>> #18 0x00005562b3079a1d in ServerLoop () at postmaster.c:1801
>> #19 0x00005562b30791b6 in PostmasterMain (argc=3, argv=0x5562b40bc5b0) at
>> postmaster.c:1473
>> #20 0x00005562b2f6d98e in main (argc=3, argv=0x5562b40bc5b0) at main.c:198
>>
>> On Mon, Oct 25, 2021 at 7:13 PM wenjing <wjzeng2012@gmail.com> wrote:
>>
>>>
>>> I missed whole row and system column. It has been fixed in v58.
>>> Please review the new code(v58) again
>>>
>>>
>>
>
>
Hi Andrew

I fixed a problem found during testing.
GTT version updated to v60.


Wenjing.