public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 1/3] bootstrap: convert Typ to a List* 4+ 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; 4+ 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] 4+ messages in thread
* Re: Does anyone ever use OPTIMIZER_DEBUG? @ 2023-10-08 21:26 David Rowley <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: David Rowley @ 2023-10-08 21:26 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: PostgreSQL Developers <[email protected]> On Tue, 3 Oct 2023 at 12:29, David Rowley <[email protected]> wrote: > > On Fri, 29 Sept 2023 at 10:59, Tom Lane <[email protected]> wrote: > > We could also discuss keeping the "tracing" aspect of it, but > > replacing debug_print_rel with pprint(rel), which'd still allow > > removal of all the "DEBUG SUPPORT" stuff at the bottom of allpaths.c. > > That's pretty much all of the maintenance-requiring stuff in it. > > To assist discussion, I've attached a patch for that. It looks like nobody is objecting to this. I understand that not everyone who might object will have read this email thread, so what I propose to do here is move along and just commit the patch to swap out debug_print_rel and use pprint instead. If that's done now then there are around 10 months where we could realistically revert this again if someone were to come forward with an objection. Sound ok? David ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Does anyone ever use OPTIMIZER_DEBUG? @ 2023-10-08 21:28 Tom Lane <[email protected]> parent: David Rowley <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Tom Lane @ 2023-10-08 21:28 UTC (permalink / raw) To: David Rowley <[email protected]>; +Cc: PostgreSQL Developers <[email protected]> David Rowley <[email protected]> writes: > It looks like nobody is objecting to this. I understand that not > everyone who might object will have read this email thread, so what I > propose to do here is move along and just commit the patch to swap out > debug_print_rel and use pprint instead. If that's done now then there > are around 10 months where we could realistically revert this again if > someone were to come forward with an objection. > Sound ok? WFM. regards, tom lane ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Does anyone ever use OPTIMIZER_DEBUG? @ 2023-10-09 02:55 David Rowley <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: David Rowley @ 2023-10-09 02:55 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: PostgreSQL Developers <[email protected]> On Mon, 9 Oct 2023 at 10:28, Tom Lane <[email protected]> wrote: > > David Rowley <[email protected]> writes: > > It looks like nobody is objecting to this. I understand that not > > everyone who might object will have read this email thread, so what I > > propose to do here is move along and just commit the patch to swap out > > debug_print_rel and use pprint instead. If that's done now then there > > are around 10 months where we could realistically revert this again if > > someone were to come forward with an objection. > > > Sound ok? > > WFM. Ok. I've pushed the patch. Let's see if anyone comes forward. David ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2023-10-09 02:55 UTC | newest] Thread overview: 4+ 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]> 2023-10-08 21:26 Re: Does anyone ever use OPTIMIZER_DEBUG? David Rowley <[email protected]> 2023-10-08 21:28 ` Re: Does anyone ever use OPTIMIZER_DEBUG? Tom Lane <[email protected]> 2023-10-09 02:55 ` Re: Does anyone ever use OPTIMIZER_DEBUG? David Rowley <[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