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/44Are there any gotchas or caveats to this? Have you been able to find a better solution for this specific problem?
--
