On Wed, Aug 3, 2022 at 12:00 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> Okay, so AtEOXact_SMgr will only get rid of unowned smgr and ours are
> owned by a fake relcache and whose lifetime is just portal memory
> context which will go away at the transaction end. So as Andres
> suggested options could be that a) we catch the error and do
> FreeFakeRelcacheEntry. b) directly use smgropen instead of
> RelationGetSmgr because actually, we do not want the owner to be set
> for these smgrs.
>
> I think option b) looks better to me, I will prepare a patch and test
> whether the error goes away with that or not.
>
Here is the patch which directly uses smgropen instead of using fake
relcache entry. We don't preserve the smgr pointer and whenever
required we again call the smgropen.
With this patch it resolved the problem for me at least what I was
able to reproduce. I was able to reproduce the WARNING messages that
Robert got as well as the valgrind error that Justin got and with this
patch both are resolved.
@Justin can you help in verifying the original issue?
Another alternative could be that continue using fake relcache entry
but instead of RelationGetSmgr() create some new function which
doesn't set the owner in the smgr.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
