Re: truncating pg_multixact/members

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: truncating pg_multixact/members
Дата
Msg-id 20140213174039.GQ6342@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: truncating pg_multixact/members  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: truncating pg_multixact/members  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: truncating pg_multixact/members  (Andres Freund <andres@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Same double precision operations, different results
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: truncating pg_multixact/members