Re: missing RelationCloseSmgr in FreeFakeRelcacheEntry? - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: missing RelationCloseSmgr in FreeFakeRelcacheEntry?
Date
Msg-id 5319B283.50507@vmware.com
Whole thread Raw
In response to Re: missing RelationCloseSmgr in FreeFakeRelcacheEntry?  (Bruce Momjian <bruce@momjian.us>)
Responses Re: missing RelationCloseSmgr in FreeFakeRelcacheEntry?  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 03/06/2014 02:18 AM, Bruce Momjian wrote:
> On Tue, Nov  5, 2013 at 08:36:32PM +0100, Andres Freund wrote:
>> On 2013-11-04 13:48:32 +0100, Andres Freund wrote:
>>> What about just unowning the smgr entry with
>>> if (rel->rd_smgr != NULL)
>>>     smgrsetowner(NULL, rel->rd_smgr)
>>> when closing the fake relcache entry?
>>>
>>> That shouldn't require any further changes than changing the comment in
>>> smgrsetowner() that this isn't something expected to frequently happen.
>>
>> Attached is a patch doing it like that, it required slightmy more
>> invasive changes than that. With the patch applied we survive replay of
>> a primary's make check run under valgrind without warnings.
>
> Where are we on this patch?

Committed now, with small changes. I made the new smgrclearowner 
function to check that the SmgrRelation object is indeed owned by the 
owner we expect, so that it doesn't unown it if it's actually owned by 
someone else. That shouldn't happen, but it seemed prudent to check.

Thanks Andres. I tried to reproduce the valgrind message you reported, 
but couldn't. How did you do it? Did this commit fix it?

And thanks for the nudge, Bruce.

- Heikki



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: GSoC on WAL-logging hash indexes
Next
From: Peter Eisentraut
Date:
Subject: Re: extension_control_path