Re: unrecognized node type while displaying a Path due to dangling pointer - Mailing list pgsql-hackers

From Jeevan Chalke
Subject Re: unrecognized node type while displaying a Path due to dangling pointer
Date
Msg-id CAM2+6=Xe2uYnj=bH_Hk5yoi9DhXA8_Y7E-JXdnynWcVh7RXc-g@mail.gmail.com
Whole thread Raw
In response to Re: unrecognized node type while displaying a Path due to dangling pointer  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: unrecognized node type while displaying a Path due to dangling pointer
List pgsql-hackers
Hi Tom,

On Tue, Jul 11, 2023 at 4:30 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jeevan Chalke <jeevan.chalke@enterprisedb.com> writes:
> Attached patch.

I would be astonished if this fixes anything.  The code still doesn't
know which paths are referenced by which other ones, and so the place
where we free a previously-added path can't know what to do.

I've speculated about adding some form of reference counting to paths
(maybe just a "pin" flag rather than a full refcount) so that we could
be smarter about this.  The existing kluge for "don't free IndexPaths"
could be replaced by setting the pin mark on any IndexPath that we
make a bitmap path from.  Up to now it hasn't seemed necessary to
generalize that hack, but maybe it's time.  Can you show a concrete
case where we are freeing a still-referenced path?

As mentioned earlier, while debugging some issues, we have put an elog displaying the foreignrel contents using nodeToString(). Like below:

@@ -1238,6 +1238,8 @@ postgresGetForeignPlan(PlannerInfo *root,
    bool        has_limit = false;
    ListCell   *lc;
 
+   elog(INFO, "foreignrel: %s", nodeToString(foreignrel));
+

And ran the postgres_fdw regression and observed many warnings saying "could not dump unrecognized node type".  Here are the queries retrieved and adjusted from postgres_fdw.sql

CREATE EXTENSION postgres_fdw;
CREATE SERVER loopback FOREIGN DATA WRAPPER postgres_fdw OPTIONS (dbname 'postgres', port '5432');
CREATE USER MAPPING FOR CURRENT_USER SERVER loopback;
CREATE TABLE t1 (c1 int NOT NULL, c2 int NOT NULL, CONSTRAINT t1_pkey PRIMARY KEY (c1));
INSERT INTO t1 SELECT id, id % 10 FROM generate_series(1, 1000) id;
ANALYZE t1;
CREATE FOREIGN TABLE ft2 (c1 int NOT NULL, c2 int NOT NULL) SERVER loopback OPTIONS (schema_name 'public', table_name 't1');

explain (verbose, costs off)
select c2, sum(c1) from ft2 group by c2 having avg(c1) < 500 and sum(c1) < 49800 order by c2;


With the above elog() in place, we can see the warning. And the pathlist has a second path as empty ({}). Which got freed but has a reference in this foreignrel.

Thanks
 

                        regards, tom lane


--
Jeevan Chalke
Senior Staff SDE, Database Architect, and Manager
Product Development




edbpostgres.com

pgsql-hackers by date:

Previous
From: Nikita Malakhov
Date:
Subject: Re: [PATCH] Infinite loop while acquiring new TOAST Oid
Next
From: Aleksander Alekseev
Date:
Subject: Re: A minor adjustment to get_cheapest_path_for_pathkeys