Re: [Proposal] Global temporary tables

曾文旌 (义从) <wenjing.zwj@alibaba-inc.com>

From: 曾文旌 <wenjing.zwj@alibaba-inc.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Konstantin Knizhnik <k.knizhnik@postgrespro.ru>, "movead.li@highgo.ca" <movead.li@highgo.ca>, Prabhat Sahu <prabhat.sahu@enterprisedb.com>, tushar <tushar.ahuja@enterprisedb.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-11-26T02:54:46Z
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.

I found that the new Patch mail failed to register to Commitfest
https://commitfest.postgresql.org/28/2349/# <https://commitfest.postgresql.org/28/2349/#>
I don't know what's wrong and how to check it?
Could you help me figure it out?



> 2020年11月25日 14:19,Pavel Stehule <pavel.stehule@gmail.com> 写道:
> 
> 
> 
> po 23. 11. 2020 v 10:27 odesílatel 曾文旌 <wenjing.zwj@alibaba-inc.com <mailto:wenjing.zwj@alibaba-inc.com>> napsal:
> 
> 
>> 2020年11月21日 02:28,Pavel Stehule <pavel.stehule@gmail.com <mailto:pavel.stehule@gmail.com>> 写道:
>> 
>> Hi
>> 
>> pá 11. 9. 2020 v 17:00 odesílatel 曾文旌 <wenjing.zwj@alibaba-inc.com <mailto:wenjing.zwj@alibaba-inc.com>> napsal:
>> I have written the README for the GTT, which contains the GTT requirements and design.
>> I found that compared to my first email a year ago, many GTT Limitations are now gone.
>> Now, I'm adding comments to some of the necessary functions.
>> 
>> There are problems with patching. Please, can you rebase your patch?
> Sure.
> I'm still working on sort code and comments.
> If you have any suggestions, please let me know.
> 
> It is broken again 
> 
> There is bad white space
> 
> +   /*
> +    * For global temp table only
> +    * use ShareUpdateExclusiveLock for ensure safety
> +    */
> +   {
> +       {
> +           "on_commit_delete_rows",
> +           "global temp table on commit options",
> +           RELOPT_KIND_HEAP | RELOPT_KIND_PARTITIONED,
> +           ShareUpdateExclusiveLock
> +       },
> +       true
> +   },  <=================
>     /* list terminator */
>     {{NULL}}
> 
> +7 OTHERS
> +Parallel query
> +Planner does not produce parallel query plans for SQL related to GTT. Because <=================
> +GTT private data cannot be accessed across processes.
> diff --git a/src/backend/catalog/Makefile b/src/backend/catalog/Makefile
> 
> 
> +/*
> + * Update global temp table relstats(relpage/reltuple/relallvisible) <========================
> + * to local hashtable
> + */
> +void
> 
> +/*
> + * Search global temp table relstats(relpage/reltuple/relallvisible) <==============
> + * from lo
> 
> and there are lot of more places ...
> 
> I found other issue
> 
> postgres=# create global temp table foo(a int);
> CREATE TABLE
> postgres=# create index on foo(a);
> CREATE INDEX
> 
> close session and in new session
> 
> postgres=# reindex index foo_a_idx ;
> WARNING:  relcache reference leak: relation "foo" not closed
> REINDEX
> 
> Regards
> 
> Pavel
> 
> 
> 
> 
> Wenjing
> 
> 
>> 
>> Regards
>> 
>> Pavel
>> 
>> 
>> 
>> Wenjing
>> 
>> 
>> 
>> 
>> 
>> > 2020年7月31日 上午4:57,Robert Haas <robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>> 写道:
>> > 
>> > On Thu, Jul 30, 2020 at 8:09 AM wenjing zeng <wjzeng2012@gmail.com <mailto:wjzeng2012@gmail.com>> wrote:
>> >> Please continue to review the code.
>> > 
>> > This patch is pretty light on comments. Many of the new functions have
>> > no header comments, for example. There are comments here and there in
>> > the body of the new functions that are added, and in places where
>> > existing code is changed there are comments here and there, but
>> > overall it's not a whole lot. There's no documentation and no README,
>> > either. Since this adds a new feature and a bunch of new SQL-callable
>> > functions that interact with that feature, the feature itself should
>> > be documented, along with its limitations and the new SQL-callable
>> > functions that interact with it. I think there should be either a
>> > lengthy comment in some suitable file, or maybe various comments in
>> > various files, or else a README file, that clearly sets out the major
>> > design principles behind the patch, and explaining also what that
>> > means in terms of features and limitations. Without that, it's really
>> > hard for anyone to jump into reviewing this code, and it will be hard
>> > for people who have to maintain it in the future to understand it,
>> > either. Or for users, for that matter.
>> > 
>> > -- 
>> > Robert Haas
>> > EnterpriseDB: http://www.enterprisedb.com <http://www.enterprisedb.com/>
>> > The Enterprise PostgreSQL Company