public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Noah Misch <[email protected]>
Cc: Aleksander Alekseev <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Marco Slot <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Christoph Berg <[email protected]>
Cc: Pavan Deolasee <[email protected]>
Subject: Re: Potential ABI breakage in upcoming minor releases
Date: Fri, 15 Nov 2024 16:13:16 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<CAJ7c6TPcUJq_Bwo69f6ysRA1UbmSh_hOOEzJ2EvM0cW=3VEh5w@mail.gmail.com>
	<CAFMSG9Hy-2-8tfmmKy7noCbA3Yn1UY2SFUwYj7wHODTO8gDm8w@mail.gmail.com>
	<CAJ7c6TMCc85YoiSKex5Sztz6bEmV-0YqL7FY=_MxxcyoMGTDfQ@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>

After some quick checking with "git diff", I can confirm that
there is no ABI break for ResultRelInfo in v12 or v13.  To fix
it in v14-v17, we could do this:

diff --git a/src/include/nodes/execnodes.h b/src/include/nodes/execnodes.h
index 418c81f4be..17b0ec5138 100644
--- a/src/include/nodes/execnodes.h
+++ b/src/include/nodes/execnodes.h
@@ -484,6 +484,9 @@ typedef struct ResultRelInfo
 	/* Have the projection and the slots above been initialized? */
 	bool		ri_projectNewInfoValid;
 
+	/* updates do LockTuple() before oldtup read; see README.tuplock */
+	bool		ri_needLockTagTuple;
+
 	/* triggers to be fired, if any */
 	TriggerDesc *ri_TrigDesc;
 
@@ -592,9 +595,6 @@ typedef struct ResultRelInfo
 	 * one of its ancestors; see ExecCrossPartitionUpdateForeignKey().
 	 */
 	List	   *ri_ancestorResultRels;
-
-	/* updates do LockTuple() before oldtup read; see README.tuplock */
-	bool		ri_needLockTagTuple;
 } ResultRelInfo;
 
 /* ----------------

(The next-to-last field varies across branches, but this general
idea will work.)  In other words, put ri_needLockTagTuple in the
same place it is in HEAD.  In other words, our current guidelines
for preserving ABI compatibility actually *created* this disaster,
because the HEAD change was fine from an ABI standpoint but what
was done in back branches was not.  So we do need to rethink how
that's worded.

			regards, tom lane

view thread (26+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Potential ABI breakage in upcoming minor releases
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox