From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Subject: | Re: missing RelationCloseSmgr in FreeFakeRelcacheEntry? |
Date: | 2013-11-01 18:36:35 |
Message-ID: | 20131101183635.GB3567@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Heikki, All,
On 2013-10-29 02:16:23 +0100, Andres Freund wrote:
> Looking a bit closer it seems to me that the fake relcache
> infrastructure seems to neglect the chance that something used the fake
> entry to read something which will have done a RelationOpenSmgr(). Which
> in turn will have set rel->rd_smgr->smgr_owner to rel.
> When we then pfree() the fake relation in FreeFakeRelcacheEntry we have
> a dangling pointer.
>
> It confuses me a bit that this doesn't cause issues during recovery more
> frequently... The code seems to have been that way since
> a213f1ee6c5a1bbe1f074ca201975e76ad2ed50c which introduced fake relcache
> entries. It looks like XLogCloseRelationCache() indirectly has done a
> RelationCloseSmgr().
This looks like it was caused by
a213f1ee6c5a1bbe1f074ca201975e76ad2ed50c which you committed, any chance
you could commit the trivial fix?
> diff --git a/src/backend/access/transam/xlogutils.c b/src/backend/access/transam/xlogutils.c
> index 5429d5e..ee7c892 100644
> --- a/src/backend/access/transam/xlogutils.c
> +++ b/src/backend/access/transam/xlogutils.c
> @@ -433,6 +433,7 @@ CreateFakeRelcacheEntry(RelFileNode rnode)
> void
> FreeFakeRelcacheEntry(Relation fakerel)
> {
> + RelationCloseSmgr(fakerel);
> pfree(fakerel);
> }
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-11-01 19:04:24 | Re: Save Hash Indexes |
Previous Message | Andres Freund | 2013-11-01 18:31:07 | buffile.c resource owner breakage on segment extension |