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

From Alvaro Herrera
Subject Re: truncating pg_multixact/members
Date
Msg-id 20140212204044.GM6342@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: truncating pg_multixact/members  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: truncating pg_multixact/members  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Tom Lane escribió:
> Alvaro Herrera <alvherre@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

Attachment

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: issue with gininsert under very high load
Next
From: Andres Freund
Date:
Subject: Re: issue with gininsert under very high load