Re: missing RelationCloseSmgr in FreeFakeRelcacheEntry?

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: missing RelationCloseSmgr in FreeFakeRelcacheEntry?
Дата
Msg-id 5319B283.50507@vmware.com
обсуждение исходный текст
Ответ на Re: missing RelationCloseSmgr in FreeFakeRelcacheEntry?  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: missing RelationCloseSmgr in FreeFakeRelcacheEntry?  (Andres Freund <andres@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: GSoC on WAL-logging hash indexes
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: extension_control_path