On 2014-02-06 20:06:03 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > That reminds me, not that I directly see how it could be responsible,
> > there's still 20131029011623.GJ20248@awork2.anarazel.de ff. around. I
> > don't think we came to a agreement in that thread how to fix the
> > problem.
>
> Hm, yeah. I'm not sure I believe Heikki's argument that we need to avoid
> closing the smgr relation. If that stuff is being used in any
> performance-critical paths then we've got trouble already.
Me neither. And I still am hesitant to start doing an unconditional
smgropen(rnode, InvalidBackendId), but maybe that's also misplaced. My
gut feeling would either to go with the very simple closing the smgr
(which was the case before the current form of the fake relcache
infrastructure!) or add support of unowning the smgr rel (as in
20131105193632.GD14819@awork2.anarazel.de).
After being slightly more awake it's even harder to see how it could be
the cause for this thread's problem. True, it's a rogue write into
palloc()ed memory that's used by somebody else, but afaics it will only
ever write a NULL. While not impossible it seems a bit of a stretch how
that could cause the symptoms.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services