Re: [HACKERS] truncating pg_multixact/members

[Alvaro Herrera]

Tom Lane escribió:
> Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> > In this new version, I added a couple of fields to VacuumStmt node.  How
> > strongly do we feel this would cause an ABI break?  Would we be more
> > comfortable if I put them at the end of the struct for 9.3 instead?
> 
> In the past we've usually added such members at the end of the struct
> in back branches (but put them in the logical place in HEAD).  I'd
> recommend doing that just on principle.

Okay.

> > Also, AutoVacOpts (used as part of reloptions) gained three extra
> > fields.  Since this is in the middle of StdRdOptions, it'd be somewhat
> > more involve to put these at the end of that struct.  This might be a
> > problem if somebody has a module calling RelationIsSecurityView().  If
> > anyone thinks we should be concerned about such an ABI change, please
> > shout quickly.
> 
> That sounds problematic --- surely StdRdOptions might be something
> extensions are making use of?

So can we assume that security_barrier is the only thing to be concerned
about?  If so, the attached patch should work around the issue by
placing it in the same physical location.  I guess if there are modules
that add extra stuff beyond StdRdOptions, this wouldn't work, but I'm
not really sure how likely this is given that our reloptions design
hasn't proven to be the most extensible thing in the world.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

*** a/src/include/utils/rel.h
--- b/src/include/utils/rel.h
***************
*** 187,193 **** typedef struct RelationData
   * be applied to relations that use this format or a superset for
   * private options data.
   */
!  /* autovacuum-related reloptions. */
  typedef struct AutoVacOpts
  {
  	bool		enabled;
--- 187,203 ----
   * be applied to relations that use this format or a superset for
   * private options data.
   */
!  /*
!   * autovacuum-related reloptions.
!   *
!   * In 9.3 starting from 9.3.3 we use a different struct definition,
!   * accomodating security_barrier inside the autovacuum struct, so that new
!   * fields could be added at the end.  This is so that third-party modules
!   * compiled with the original definition of the struct can continue to
!   * access the security_barrier field in its original physical location,
!   * avoiding an ABI break.  (9.4 and up use the normal definition, where
!   * security_barrier is placed outside autovacuum options.)
!   */
  typedef struct AutoVacOpts
  {
  	bool		enabled;
***************
*** 200,213 **** typedef struct AutoVacOpts
  	int			freeze_table_age;
  	float8		vacuum_scale_factor;
  	float8		analyze_scale_factor;
  } AutoVacOpts;
  
  typedef struct StdRdOptions
  {
  	int32		vl_len_;		/* varlena header (do not touch directly!) */
  	int			fillfactor;		/* page fill factor in percent (0..100) */
! 	AutoVacOpts autovacuum;		/* autovacuum-related options */
! 	bool		security_barrier;		/* for views */
  } StdRdOptions;
  
  #define HEAP_MIN_FILLFACTOR			10
--- 210,226 ----
  	int			freeze_table_age;
  	float8		vacuum_scale_factor;
  	float8		analyze_scale_factor;
+ 	bool		security_barrier;
+ 	int			multixact_freeze_min_age;
+ 	int			multixact_freeze_max_age;
+ 	int			multixact_freeze_table_age;
  } AutoVacOpts;
  
  typedef struct StdRdOptions
  {
  	int32		vl_len_;		/* varlena header (do not touch directly!) */
  	int			fillfactor;		/* page fill factor in percent (0..100) */
! 	AutoVacOpts	autovacuum;		/* autovacuum -- includes security_barrier */
  } StdRdOptions;
  
  #define HEAP_MIN_FILLFACTOR			10
***************
*** 238,247 **** typedef struct StdRdOptions
  /*
   * RelationIsSecurityView
   *		Returns whether the relation is security view, or not
   */
  #define RelationIsSecurityView(relation)	\
  	((relation)->rd_options ?				\
! 	 ((StdRdOptions *) (relation)->rd_options)->security_barrier : false)
  
  /*
   * RelationIsValid
--- 251,264 ----
  /*
   * RelationIsSecurityView
   *		Returns whether the relation is security view, or not
+  *
+  * XXX this definition copes with unusual placement of the field to preserve
+  * ABI compatibility with releases prior to 9.3.3.
   */
  #define RelationIsSecurityView(relation)	\
  	((relation)->rd_options ?				\
! 	 ((StdRdOptions *) (relation)->rd_options)->autovacuum.security_barrier : \
! 	 false)
  
  /*
   * RelationIsValid

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers