Message-ID: <a7880f4d-1d74-582a-ada7-dad168d046d1@enterprisedb.com>
Date: Tue, 5 Apr 2022 15:02:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.2
Subject: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE
 overlaps a checkpoint.]
Content-Language: en-US
To: Robert Haas <rhaas@postgresql.org>, pgsql-hackers@postgresql.org
References: <E1nXTCX-001DGF-R0@gemulon.postgresql.org>
From: Markus Wanner <markus.wanner@enterprisedb.com>
In-Reply-To: <E1nXTCX-001DGF-R0@gemulon.postgresql.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/a7880f4d-1d74-582a-ada7-dad168d046d1%40enterprisedb.com>
Precedence: bulk


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