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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
