public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 2/5] Allow composite types in bootstrap 2+ messages / 2 participants [nested] [flat]
* [PATCH 2/5] Allow composite types in bootstrap @ 2020-11-17 15:28 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Justin Pryzby @ 2020-11-17 15:28 UTC (permalink / raw) --- src/backend/bootstrap/bootstrap.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c index 18eb62ca47..e4fc75ab84 100644 --- a/src/backend/bootstrap/bootstrap.c +++ b/src/backend/bootstrap/bootstrap.c @@ -916,6 +916,7 @@ gettype(char *type) { if (Typ != NIL) { + static bool did_reread PG_USED_FOR_ASSERTS_ONLY = false; /* Already reread pg_types */ ListCell *lc; foreach (lc, Typ) @@ -927,6 +928,33 @@ gettype(char *type) return app->am_oid; } } + + /* + * The type wasn't known; check again to handle composite + * types, added since first populating the array. + */ + + /* + * Once all the types are populated and we handled composite + * types, shouldn't need to do that again. + */ + Assert(!did_reread); + did_reread = true; + + list_free_deep(Typ); + Typ = NULL; + populate_typ_array(); + + /* Need to avoid infinite recursion... */ + foreach (lc, Typ) + { + struct typmap *app = lfirst(lc); + if (strncmp(NameStr(app->am_typ.typname), type, NAMEDATALEN) == 0) + { + Ap = app; + return app->am_oid; + } + } } else { -- 2.26.2 --------------614DDB87AFFED893713AC0E9 Content-Type: text/x-patch; charset=UTF-8; name="0003-Extended-statistics-on-expressions-20210304.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0003-Extended-statistics-on-expressions-20210304.patch" ^ permalink raw reply [nested|flat] 2+ messages in thread
* Should work_mem be stable for a prepared statement? @ 2025-02-27 18:42 Jeff Davis <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Jeff Davis @ 2025-02-27 18:42 UTC (permalink / raw) To: pgsql-hackers As a part of this discussion: https://www.postgresql.org/message-id/CAJVSvF6s1LgXF6KB2Cz68sHzk%2Bv%2BO_vmwEkaon%3DH8O9VcOr-tQ%40ma... James pointed out something interesting, which is that a prepared statement enforces the work_mem limit at execution time, which might be different from the work_mem at the time the statement was prepared. For instance: SET work_mem='1GB'; PREPARE foo AS ...; -- plans using 1GB limit SET work_mem='1MB'; EXECUTE foo; -- enforces 1MB limit My first reaction is that it's not right because the costing for the plan is completely bogus with a different work_mem. It would make more sense to me if we either (a) enforced work_mem as it was at the time of planning; or (b) replanned if executed with a different work_mem (similar to how we replan sometimes with different parameters). But I'm not sure whether someone might be relying on the existing behavior? If we were to implement (a) or (b), we couldn't use the work_mem global directly, we'd need to save it in the plan, and enforce using the plan's saved value. But that might be a good change anyway. In theory we might need to do something similar for hash_mem_multiplier, too. Regards, Jeff Davis ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2025-02-27 18:42 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-11-17 15:28 [PATCH 2/5] Allow composite types in bootstrap Justin Pryzby <[email protected]> 2025-02-27 18:42 Should work_mem be stable for a prepared statement? Jeff Davis <[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