| 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
| 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 |