On Sat, 1 Jun 2024 at 12:55, Michael Paquier wrote:
> This patch looks like a good idea, so +1 from here.
Thank you to both of you for reviewing this. I've now pushed the patch.
David
On Fri, May 31, 2024 at 12:35:58PM +1200, David Rowley wrote:
> This follows what we do in other places. If you look at explain.c,
> you'll see lots of "???"s.
>
> I think if you're worried about corrupted memory, then garbled output
> in pg_get_backend_memory_contexts wouldn't be that high on th
> On May 30, 2024, at 5:36 PM, David Rowley wrote:
>
> On Fri, 31 May 2024 at 07:21, David Christensen wrote:
>> Giving this a once-through, this seems straightforward and useful. I
>> have a slight preference for keeping "name" the first field in the
>> view and moving "type" to the second,
On Fri, 31 May 2024 at 07:21, David Christensen wrote:
> Giving this a once-through, this seems straightforward and useful. I
> have a slight preference for keeping "name" the first field in the
> view and moving "type" to the second, but that's minor.
Not having it first make sense, but I don't
Hi David,
Giving this a once-through, this seems straightforward and useful. I
have a slight preference for keeping "name" the first field in the
view and moving "type" to the second, but that's minor.
Just confirming that the allocator types are not extensible without a
recompile, since it's us
On Tue, 16 Apr 2024 at 13:30, David Rowley wrote:
> In [1] Andres mentioned that there's no way to determine the memory
> context type in pg_backend_memory_contexts. This is a bit annoying as
> I'd like to add a test to exercise BumpStats().
>
> Having the context type in the test's expected outpu
In [1] Andres mentioned that there's no way to determine the memory
context type in pg_backend_memory_contexts. This is a bit annoying as
I'd like to add a test to exercise BumpStats().
Having the context type in the test's expected output helps ensure we
are exercising BumpStats() and any future
