On 24.03.22 20:32, Robert Haas wrote:
Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.
This patch changed the delayChkpt field of struct PGPROC from bool to
int. Back-porting this change could be considered an API breaking
change for extensions using this field.
I'm not certain about padding behavior of compilers in general (or
standards requirements around that), but at least on my machine, it
seems sizeof(PGPROC) did not change, so padding led to subsequent fields
still having the same offset.
Nonetheless, the meaning of the field itself changed. And the
additional assert now also triggers for the following pseudo-code of the
extension I'm concerned about:
/*
* Prevent checkpoints being emitted in between additional
* information in the logical message and the following
* prepare record.
*/
MyProc->delayChkpt = true;
LogLogicalMessage(...);
/* Note that this will also reset the delayChkpt flag. */
PrepareTransaction(...);
Now, I'm well aware this is not an official API, it just happens to be
accessible for extensions. So I guess the underlying question is: What
can extension developers expect? Which parts are okay to change even in
stable branches and which can be relied upon to remain stable?
And for this specific case: Is it worth reverting this change and
applying a fully backwards compatible fix, instead?
Regards
Markus Wanner
