Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
От | Dilip Kumar |
---|---|
Тема | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |
Дата | |
Msg-id | CAFiTN-v4u2WJT6y1n4wtM4Z3tffJonT7zuRKegYao9p-Oyb07Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: