Hi there,
I want to clarify the comment I found in `errfinish`:
```
Reset InterruptHoldoffCount in case we ereport'd from inside an
interrupt holdoff section. (We assume here that no handler will
itself be inside a holdoff section. If necessary, such a handler
could **save and restore** InterruptHoldoffCount for itself, but this
should make life easier for most.)
```
(emphasis is mine)
There is a case where errors are handled by either PG_TRY() blocks to do
some additional cleanup. There is also another case in pgrx (Rust binding)
and cppgres (C++) where sigsetjmp is used to transform errors into host
language primitives, such as errors, panics, or exceptions – either to be
handled there or bubble up all the way back to the "surface" and to be
translated into errors again.
The problem I observe is that acquiring an `LWLock` increments
`InterruptHoldoffCount`, and releasing it requires `InterruptHoldoffCount`
to be greater than zero. If I understand everything correctly, it would
still be essential to release the locks even after encountering an error,
even though the holdoff count is zero. Let's imagine this high-level
scenario:
```
LWLockAcquire();
error = <ffi_boundary> { call into Postgres function }
LWLockRelease(); // <-- fails with an assertion if there was an error
// Failed assertion: `Assert(InterruptHoldoffCount > 0)`
```
(can look differently, for example, RAII pattern in C++)
In my case, I've decided to try following the emphasized note in the
comment, saving and restoring the count:
https://github.com/cppgres/cppgres/pull/44
Are there any gotchas or caveats to this? Have you been able to find a
better solution for this specific problem?
--
Founder at Omnigres
https://omnigres.com
