Saving and restoring InterruptHoldoffCount
От | Yurii Rashkovskii |
---|---|
Тема | Saving and restoring InterruptHoldoffCount |
Дата | |
Msg-id | CAG=VW17+_V3oC9OpThUj7bm+5mhWa2CqQi+BmatZmqeLLcaWOA@mail.gmail.com обсуждение исходный текст |
Список | pgsql-hackers |
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.)
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)
(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();
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
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
В списке pgsql-hackers по дате отправления: