Re: RFC: Logging plan of the running query
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: James Coleman <jtc331@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, torikoshia <torikoshia@oss.nttdata.com>, pgsql-hackers@lists.postgresql.org, Étienne BERSAC <etienne.bersac@dalibo.com>, ashutosh.bapat.oss@gmail.com, rafaelthca@gmail.com, jian.universality@gmail.com
Date: 2024-02-23T04:52:32Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
ecpg: Catch zero-length Unicode identifiers correctly
- a18b6d2dc288 15.0 cited
-
Improve warning message in pg_signal_backend()
- 7fa945b857cc 15.0 cited
-
Add assert to ensure that page locks don't participate in deadlock cycle.
- 72e78d831ab5 13.0 cited
On Thu, Feb 22, 2024 at 6:25 AM James Coleman <jtc331@gmail.com> wrote: > This is potentially a bit of a wild idea, but I wonder if having some > kind of argument to CHECK_FOR_INTERRUPTS() signifying we're in > "normal" as opposed to "critical" (using that word differently than > the existing critical sections) would be worth it. It's worth considering, but the definition of "normal" vs. "critical" might be hard to pin down. Or, we might end up with a definition that is specific to this particular case and not generalizable to others. -- Robert Haas EDB: http://www.enterprisedb.com