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-11-11 08:15:09
Message-ID: CA+B_3V=PzKs4m1FK1tXSCTYMVWgQZ0HUxG7f7FwzKBWwn_5ZXQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

wenjing <wjzeng2012(at)gmail(dot)com> 于2021年11月9日周二 下午4:51写道:

>
>
> wenjing <wjzeng2012(at)gmail(dot)com> 于2021年10月30日周六 上午1:28写道:
>
>>
>>
>> Andrew Bille <andrewbille(at)gmail(dot)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(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 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(at)gmail(dot)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.
>
>
>
>

Fixed a bug in function pg_gtt_attached_pid.
Looking forward to your reply.

Wenjing

Attachment Content-Type Size
0002-gtt-v61-doc.patch application/octet-stream 7.5 KB
0001-gtt-v61-reademe.patch application/octet-stream 7.5 KB
0003-gtt-v61-implementation.patch application/octet-stream 173.6 KB
0004-gtt-v61-regress.patch application/octet-stream 81.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message osumi.takamichi@fujitsu.com 2021-11-11 09:20:44 RE: Optionally automatically disable logical replication subscriptions on error
Previous Message Greg Nancarrow 2021-11-11 08:14:26 Re: Data is copied twice when specifying both child and parent table in publication