Re: truncating pg_multixact/members - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: truncating pg_multixact/members
Date
Msg-id 20140213174039.GQ6342@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: truncating pg_multixact/members  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: truncating pg_multixact/members  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: truncating pg_multixact/members  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund escribió:
> On 2014-02-12 17:40:44 -0300, Alvaro Herrera wrote:
> > > > 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.
> 
> Aw. How instead about temporarily introducing AutoVacMXactOpts or
> something? Changing the name of the member variable sounds just as
> likely to break things.

Yes, that's what I did --- see the attached patch, which I would apply
on top of the code for master and would be only in 9.3.  The idea here
is to keep the existing bits of StdRdOpts identical, so that macros such
as RelationIsSecurityView() that were compiled with the old rel.h
continue to work unchanged and without requiring a recompile.

> > 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.
> 
> Hm, I don't see how it'd be problematic, even if they do. I don't really
> understand the design of the reloptions code, but afaics, they shouldn't
> do so by casting around rd_options but by parsing it anew, right?

Now that I think about it, I don't think adding stuff at the end of
StdRdOptions has anything to do with adding nonstandard options.  So if
we extend that struct we're not breaking any ABI contract.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Same double precision operations, different results
Next
From: Alvaro Herrera
Date:
Subject: Re: truncating pg_multixact/members