Re: Parent/child context relation in pg_get_backend_memory_contexts() - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Parent/child context relation in pg_get_backend_memory_contexts()
Date
Msg-id CA+TgmoaiKmJHLk=8e2r71Y299na7iNXYBDcGdNVfqHv17nSNQA@mail.gmail.com
Whole thread Raw
In response to Re: Parent/child context relation in pg_get_backend_memory_contexts()  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Parent/child context relation in pg_get_backend_memory_contexts()
List pgsql-hackers
On Mon, Jul 15, 2024 at 6:44 AM David Rowley <dgrowleyml@gmail.com> wrote:
> Unfortunately, this wouldn't align with the goals of the patch. Going
> back to Melih's opening paragraph in the initial email, he mentions
> that there's currently no *reliable* way to determine the parent/child
> relationship in this view.
>
> There's been a few different approaches to making this reliable. The
> first patch had "parent_id" and "id" columns.  That required a WITH
> RECURSIVE query.  To get away from having to write such complex
> queries, the "path" column was born.  I'm now trying to massage that
> into something that's as easy to use and intuitive as possible. I've
> gotta admit, I don't love the patch. That's not Melih's fault,
> however. It's just the nature of what we're working with.

I'm not against what you're trying to do here, but I feel like you
might be over-engineering it. I don't think there was anything really
wrong with what Melih was doing, and I don't think there's anything
really wrong with converting the path to an array of strings, either.
Sure, it might not be perfect, but future patches could always remove
the name duplication. This is a debugging facility that will be used
by a tiny minority of users, and if some non-uniqueness gets
reintroduced in the future, it's not a critical defect and can just be
fixed when it's noticed. That said, if you want to go with the integer
IDs and want to spend more time massaging it, I also think that's
fine. I simply don't believe it's the only way forward here. YMMV, but
my opinion is that none of these approaches have such critical flaws
that we need to get stressed about it.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: long-standing data loss bug in initial sync of logical replication
Next
From: Robert Haas
Date:
Subject: Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal