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.steh...@gmail.com> 写道： > > > > po 23. 11. 2020 v 10:27 odesílatel 曾文旌 <wenjing....@alibaba-inc.com > <mailto:wenjing....@alibaba-inc.com>> napsal: > > >> 2020年11月21日 02:28，Pavel Stehule <pavel.steh...@gmail.com >> <mailto:pavel.steh...@gmail.com>> 写道： >> >> Hi >> >> pá 11. 9. 2020 v 17:00 odesílatel 曾文旌 <wenjing....@alibaba-inc.com >> <mailto:wenjing....@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 <robertmh...@gmail.com >> > <mailto:robertmh...@gmail.com>> 写道： >> > >> > On Thu, Jul 30, 2020 at 8:09 AM wenjing zeng <wjzeng2...@gmail.com >> > <mailto:wjzeng2...@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
smime.p7s
Description: S/MIME cryptographic signature
