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
--------------1F4A19FEB5D90C72707AFA7B
Content-Type: text/x-patch; charset=UTF-8;
name="0002-Allow-composite-types-in-bootstrap-20210122.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="0002-Allow-composite-types-in-bootstrap-20210122.patch"
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Segmentation fault on proc exit after dshash_find_or_insert
@ 2026-01-14 09:36 Álvaro Herrera <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Álvaro Herrera @ 2026-01-14 09:36 UTC (permalink / raw)
To: Amit Langote <[email protected]>; +Cc: Rahila Syed <[email protected]>; Andres Freund <[email protected]>; pgsql-hackers
On 2025-Dec-18, Amit Langote wrote:
> Thanks. Updated the commit message too to be more accurate in the
> attached updated patch.
Looks good to me. I would add an Assert(num_held_lwlocks == 0) at the
end of LWLockReleaseAll(), to make it clear that it's idempotent (which
is important for the case where ProcKill will call it again shortly
after).
Are you going to push this soon?
Looking at ProcKill, I notice that we do some LWLock ops after its
LWLockReleaseAll() call, which seems a bit silly. Why not do that right
after the "if (MyProc->lockGroupLeader != NULL)" block instead? Nothing
uses LWLocks from there on. This can be a separate commit.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Segmentation fault on proc exit after dshash_find_or_insert
@ 2026-01-14 13:56 Amit Langote <[email protected]>
parent: Álvaro Herrera <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Amit Langote @ 2026-01-14 13:56 UTC (permalink / raw)
To: Álvaro Herrera <[email protected]>; +Cc: Rahila Syed <[email protected]>; Andres Freund <[email protected]>; pgsql-hackers
Hi Alvaro,
On Wed, Jan 14, 2026 at 6:36 PM Álvaro Herrera <[email protected]> wrote
> On 2025-Dec-18, Amit Langote wrote:
>
> > Thanks. Updated the commit message too to be more accurate in the
> > attached updated patch.
>
> Looks good to me.
Thanks for looking.
> I would add an Assert(num_held_lwlocks == 0) at the
> end of LWLockReleaseAll(), to make it clear that it's idempotent (which
> is important for the case where ProcKill will call it again shortly
> after).
Makes sense. Will do.
> Are you going to push this soon?
Yes, I will try tomorrow.
> Looking at ProcKill, I notice that we do some LWLock ops after its
> LWLockReleaseAll() call, which seems a bit silly. Why not do that right
> after the "if (MyProc->lockGroupLeader != NULL)" block instead? Nothing
> uses LWLocks from there on. This can be a separate commit.
Just to confirm: you're suggesting moving the LWLockReleaseAll() call
to after the "if (MyProc->lockGroupLeader != NULL)" block? Makes sense
-- odd to release all locks right before then going ahead and
acquiring one. Agreed it should be a separate commit.
--
Thanks, Amit Langote
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Segmentation fault on proc exit after dshash_find_or_insert
@ 2026-01-16 05:52 Amit Langote <[email protected]>
parent: Amit Langote <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Amit Langote @ 2026-01-16 05:52 UTC (permalink / raw)
To: Álvaro Herrera <[email protected]>; +Cc: Rahila Syed <[email protected]>; Andres Freund <[email protected]>; pgsql-hackers
Hi Álvaro,
On Wed, Jan 14, 2026 at 10:56 PM Amit Langote <[email protected]> wrote:
> On Wed, Jan 14, 2026 at 6:36 PM Álvaro Herrera <[email protected]> wrote
> > I would add an Assert(num_held_lwlocks == 0) at the
> > end of LWLockReleaseAll(), to make it clear that it's idempotent (which
> > is important for the case where ProcKill will call it again shortly
> > after).
>
> Makes sense. Will do.
Done and pushed. I struggled to write a comment to describe the Assert though.
--
Thanks, Amit Langote
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-01-16 05:52 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]>
2026-01-14 09:36 Re: Segmentation fault on proc exit after dshash_find_or_insert Álvaro Herrera <[email protected]>
2026-01-14 13:56 ` Re: Segmentation fault on proc exit after dshash_find_or_insert Amit Langote <[email protected]>
2026-01-16 05:52 ` Re: Segmentation fault on proc exit after dshash_find_or_insert Amit Langote <[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