public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 1/3] bootstrap: convert Typ to a List* 3+ messages / 3 participants [nested] [flat]
* [PATCH 1/3] bootstrap: convert Typ to a List* @ 2020-11-20 02:48 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Justin Pryzby @ 2020-11-20 02:48 UTC (permalink / raw) --- src/backend/bootstrap/bootstrap.c | 69 ++++++++++++++----------------- 1 file changed, 31 insertions(+), 38 deletions(-) diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c index 6f615e6622..18eb62ca47 100644 --- a/src/backend/bootstrap/bootstrap.c +++ b/src/backend/bootstrap/bootstrap.c @@ -159,7 +159,7 @@ struct typmap FormData_pg_type am_typ; }; -static struct typmap **Typ = NULL; +static List *Typ = NIL; /* List of struct typmap* */ static struct typmap *Ap = NULL; static Datum values[MAXATTR]; /* current row's attribute values */ @@ -597,7 +597,7 @@ boot_openrel(char *relname) * pg_type must be filled before any OPEN command is executed, hence we * can now populate the Typ array if we haven't yet. */ - if (Typ == NULL) + if (Typ == NIL) populate_typ_array(); if (boot_reldesc != NULL) @@ -688,7 +688,7 @@ DefineAttr(char *name, char *type, int attnum, int nullness) typeoid = gettype(type); - if (Typ != NULL) + if (Typ != NIL) { attrtypes[attnum]->atttypid = Ap->am_oid; attrtypes[attnum]->attlen = Ap->am_typ.typlen; @@ -877,36 +877,25 @@ populate_typ_array(void) Relation rel; TableScanDesc scan; HeapTuple tup; - int nalloc; - int i; - - Assert(Typ == NULL); - nalloc = 512; - Typ = (struct typmap **) - MemoryContextAlloc(TopMemoryContext, nalloc * sizeof(struct typmap *)); + Assert(Typ == NIL); rel = table_open(TypeRelationId, NoLock); scan = table_beginscan_catalog(rel, 0, NULL); - i = 0; while ((tup = heap_getnext(scan, ForwardScanDirection)) != NULL) { Form_pg_type typForm = (Form_pg_type) GETSTRUCT(tup); + struct typmap *newtyp; + MemoryContext old; - /* make sure there will be room for a trailing NULL pointer */ - if (i >= nalloc - 1) - { - nalloc *= 2; - Typ = (struct typmap **) - repalloc(Typ, nalloc * sizeof(struct typmap *)); - } - Typ[i] = (struct typmap *) - MemoryContextAlloc(TopMemoryContext, sizeof(struct typmap)); - Typ[i]->am_oid = typForm->oid; - memcpy(&(Typ[i]->am_typ), typForm, sizeof(Typ[i]->am_typ)); - i++; + old = MemoryContextSwitchTo(TopMemoryContext); + newtyp = (struct typmap *) palloc(sizeof(struct typmap)); + Typ = lappend(Typ, newtyp); + MemoryContextSwitchTo(old); + + newtyp->am_oid = typForm->oid; + memcpy(&newtyp->am_typ, typForm, sizeof(newtyp->am_typ)); } - Typ[i] = NULL; /* Fill trailing NULL pointer */ table_endscan(scan); table_close(rel, NoLock); } @@ -925,16 +914,17 @@ populate_typ_array(void) static Oid gettype(char *type) { - if (Typ != NULL) + if (Typ != NIL) { - struct typmap **app; + ListCell *lc; - for (app = Typ; *app != NULL; app++) + foreach (lc, Typ) { - if (strncmp(NameStr((*app)->am_typ.typname), type, NAMEDATALEN) == 0) + struct typmap *app = lfirst(lc); + if (strncmp(NameStr(app->am_typ.typname), type, NAMEDATALEN) == 0) { - Ap = *app; - return (*app)->am_oid; + Ap = app; + return app->am_oid; } } } @@ -980,14 +970,17 @@ boot_get_type_io_data(Oid typid, if (Typ != NULL) { /* We have the boot-time contents of pg_type, so use it */ - struct typmap **app; - struct typmap *ap; - - app = Typ; - while (*app && (*app)->am_oid != typid) - ++app; - ap = *app; - if (ap == NULL) + struct typmap *ap = NULL; + ListCell *lc; + + foreach (lc, Typ) + { + ap = lfirst(lc); + if (ap->am_oid == typid) + break; + } + + if (!ap || ap->am_oid != typid) elog(ERROR, "type OID %u not found in Typ list", typid); *typlen = ap->am_typ.typlen; -- 2.26.2 --------------76B8D0DC8AE327D516738282 Content-Type: text/x-patch; charset=UTF-8; name="0002-Allow-composite-types-in-bootstrap-20210108.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0002-Allow-composite-types-in-bootstrap-20210108.patch" ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Commitfest 2024-01 first week update @ 2024-01-09 22:18 Robert Haas <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Robert Haas @ 2024-01-09 22:18 UTC (permalink / raw) To: vignesh C <[email protected]>; +Cc: pgsql-hackers Hi, I think we need to be more aggressive about marking things returned with feedback when they don't get updated. If a patch is waiting for reviews for a long time, well, that's one thing. Maybe we eventually close it due to lack of interest in reviewing it, but that should be done cautiously, as it will understandably piss people off. But I regularly find patches in the CommitFest which have been waiting on author for multiple commitfests and are just repeatedly moved forward. That's crazy to me. It makes the CommitFest application fill up with junk that obscures what actually needs to be dealt with. ...Robert ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Commitfest 2024-01 first week update @ 2024-01-10 03:47 vignesh C <[email protected]> parent: Robert Haas <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: vignesh C @ 2024-01-10 03:47 UTC (permalink / raw) To: Robert Haas <[email protected]>; +Cc: pgsql-hackers On Wed, 10 Jan 2024 at 03:48, Robert Haas <[email protected]> wrote: > > Hi, > > I think we need to be more aggressive about marking things returned > with feedback when they don't get updated. If a patch is waiting for > reviews for a long time, well, that's one thing. Maybe we eventually > close it due to lack of interest in reviewing it, but that should be > done cautiously, as it will understandably piss people off. But I > regularly find patches in the CommitFest which have been waiting on > author for multiple commitfests and are just repeatedly moved forward. > That's crazy to me. It makes the CommitFest application fill up with > junk that obscures what actually needs to be dealt with. I also noticed that many patches get carried forward to the next commitfest. I will start highlighting these kinds of patches to the author, request them to act upon the patches and return the patch if nothing is done in this commitfest. I'm also working on the needs review patches, I have already withdrawn one of my patches yesterday at [1] which got no response for a long time. I also got one on my colleagues's patch to be withdrawn by requesting him internally at [2]. I will be posting these kinds of patches in my weekly update. It will be good if one of the senior folks reply whether to take it forward or not, that will help me in taking a decision quickly on what to do with these patches. One kind suggestion for all the patches which have been inactive for a long time is for the author to re-assess the patch once again and act on the entry voluntarily which will help the committers and reviewers in spending time on the real patch which requires focus. [1] - https://www.postgresql.org/message-id/CALDaNm1AQZYgT0tALRrkvpP1Q%2B8%2Be7vkGCUjQ-jim1C0q3e%3DzA%40ma... [2] - https://www.postgresql.org/message-id/[email protected]... Regards, Vignesh ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-01-10 03:47 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-11-20 02:48 [PATCH 1/3] bootstrap: convert Typ to a List* Justin Pryzby <[email protected]> 2024-01-09 22:18 Re: Commitfest 2024-01 first week update Robert Haas <[email protected]> 2024-01-10 03:47 ` Re: Commitfest 2024-01 first week update vignesh C <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox