Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
От | Dilip Kumar |
---|---|
Тема | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |
Дата | |
Msg-id | CAFiTN-thCGvRF0_WftbDc0KFagB3vgHHGrpNdRMJ6vtkObEMoA@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
Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |
Список | pgsql-hackers |
On Wed, Aug 3, 2022 at 1:41 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > 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. Another version of the patch which closes the smgr at the end using smgrcloserellocator() and I have also added a commit message. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: