public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 2/3] Allow composite types in bootstrap 2+ messages / 2 participants [nested] [flat]
* [PATCH 2/3] 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 --------------8FD28E9B65A94BB176003065 Content-Type: text/x-patch; charset=UTF-8; name="0003-Extended-statistics-on-expressions-20210116.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0003-Extended-statistics-on-expressions-20210116.patch" ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Wrong results from Parallel Hash Full Join @ 2023-04-12 14:57 Melanie Plageman <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Melanie Plageman @ 2023-04-12 14:57 UTC (permalink / raw) To: Richard Guo <[email protected]>; +Cc: pgsql-hackers On Wed, Apr 12, 2023 at 7:36 AM Richard Guo <[email protected]> wrote: > > I came across $subject and reduced the repro query as below. > > create table a (i int); > create table b (i int); > insert into a values (1); > insert into b values (2); > update b set i = 2; > > set min_parallel_table_scan_size to 0; > set parallel_tuple_cost to 0; > set parallel_setup_cost to 0; > > # explain (costs off) select * from a full join b on a.i = b.i; > QUERY PLAN > ------------------------------------------ > Gather > Workers Planned: 2 > -> Parallel Hash Full Join > Hash Cond: (a.i = b.i) > -> Parallel Seq Scan on a > -> Parallel Hash > -> Parallel Seq Scan on b > (7 rows) > > # select * from a full join b on a.i = b.i; > i | i > ---+--- > 1 | > (1 row) > > Tuple (NULL, 2) is missing from the results. Thanks so much for reporting this, Richard. This is a fantastic minimal repro! So, I looked into this, and it seems that, as you can imagine, the tuple in b is hot updated, resulting in a heap only tuple. t_ctid | raw_flags --------+---------------------------------------------------------------------- (0,2) | {HEAP_XMIN_COMMITTED,HEAP_XMAX_COMMITTED,HEAP_HOT_UPDATED} (0,2) | {HEAP_XMIN_COMMITTED,HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE} In ExecParallelScanHashTableForUnmatched() we don't emit the NULL-extended tuple because HeapTupleHeaderHasMatch() is true for our desired tuple. while (hashTuple != NULL) { if (!HeapTupleHeaderHasMatch(HJTUPLE_MINTUPLE(hashTuple))) { HeapTupleHeaderHasMatch() checks if HEAP_TUPLE_HAS_MATCH is set. In htup_details.h, you will see that HEAP_TUPLE_HAS_MATCH is defined as HEAP_ONLY_TUPLE /* * HEAP_TUPLE_HAS_MATCH is a temporary flag used during hash joins. It is * only used in tuples that are in the hash table, and those don't need * any visibility information, so we can overlay it on a visibility flag * instead of using up a dedicated bit. */ #define HEAP_TUPLE_HAS_MATCH HEAP_ONLY_TUPLE /* tuple has a join match */ If you redefine HEAP_TUPLE_HAS_MATCH as something that isn't already used, say 0x1800, the query returns correct results. QUERY PLAN ------------------------------------------ Gather Workers Planned: 2 -> Parallel Hash Full Join Hash Cond: (a.i = b.i) -> Parallel Seq Scan on a -> Parallel Hash -> Parallel Seq Scan on b (7 rows) i | i ---+--- 1 | | 2 (2 rows) The question is, why does this only happen for a parallel full hash join? unpa postgres=# explain (costs off) select * from a full join b on a.i = b.i; QUERY PLAN --------------------------- Hash Full Join Hash Cond: (a.i = b.i) -> Seq Scan on a -> Hash -> Seq Scan on b (5 rows) postgres=# select * from a full join b on a.i = b.i; i | i ---+--- 1 | | 2 (2 rows) I imagine it has something to do with what tuples are put in the parallel hashtable. I am about to investigate that but just wanted to share what I had so far. - Melanie ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2023-04-12 14:57 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/3] Allow composite types in bootstrap Justin Pryzby <[email protected]> 2023-04-12 14:57 Re: Wrong results from Parallel Hash Full Join Melanie Plageman <[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