Re: Enhancing Memory Context Statistics Reporting

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Rahila Syed <rahilasyed90(at)gmail(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Enhancing Memory Context Statistics Reporting
Date: 2026-01-19 18:02:27
Message-ID: CA+TgmoY7B4oM4MP3PTwVYTa3YKOwjCWFLYitY4FqoT5VN+rw7Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 19, 2026 at 12:31 PM Rahila Syed <rahilasyed90(at)gmail(dot)com> wrote:
> Starting a transaction from CFI works for a client backend but
> not for auxiliary processes. When I try to execute StartTransaction()
> from a checkpointer process, the following assertion fails,
> Assert(MyProc->vxid.procNumber == vxid.procNumber);
> This is because MyProc->vxid.procNumber is not set for auxiliary
> processes.

Unfortunately, somebody is going to need to think through - and
perhaps test - what happens in each individual type of background
process -- not just auxiliary processes but also background workers,
including but not limited to parallel workers. Some of them have error
recovery logic that is similar to transaction cleanup but only covers
a subset of things, in which case the question will be whether that
logic handles all the kinds of resources that this code might acquire.
Some of them may just straight up kill the process if an error occurs,
which is fine for this patch as long as it only happens in extreme
situations (e.g. OOM).

In other words, we don't necessarily need a transaction specifically,
but we need whatever form of error recovery is in use in any given
process to be appropriate to the code that this patch proposes to
execute. For a regular backend, that's a transaction.

Also worth noting: I don't think that all backend types actually use
CHECK_FOR_INTERRUPTS(). For those that don't, other updates may be
needed to make this feature work.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul A Jungwirth 2026-01-19 18:33:02 Re: SQL:2011 Application Time Update & Delete
Previous Message Marcos Pegoraro 2026-01-19 17:44:18 Re: Initial COPY of Logical Replication is too slow