On Fri, Mar 18, 2022 at 1:44 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Mar 16, 2022 at 12:53 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > Thanks Ashutosh and Robert. Other pacthes cleanly applied on this
> > patch still generated a new version so that we can find all patches
> > together. There are no other changes.
>
> I committed my v3 of my refactoring patch, here 0001.
>
> I'm working over the comments in the rest of the patch series and will
> post an updated version when I get done. I think I will likely merge
> all the remaining patches together just to make it simpler to manage;
> we can split things out again if we need to do that.
Thanks for the effort.
> One question that occurred to me when looking this over is whether, or
> why, it's safe against concurrent smgr invalidations.
We are only accessing the smgr of the source database and the
destination database. And there is no one else that can be connected
to the source db and the destination db is not visible to anyone. So
do we really need to worry about the concurrent smgr invalidation?
What am I missing?
It seems to me
> that every loop in the new CREATE DATABASE code needs to
> CHECK_FOR_INTERRUPTS() -- some do already -- and when they do that,
Yes, the pg_class reading code is missing this check so we need to put
it. But copying code like
CreateDatabaseUsingWalLog() have it inside the deepest loop in
RelationCopyStorageUsingBuffer() and similarly
CreateDatabaseUsingFileCopy() have it in copydir(). Maybe we should
put it in all loop so that we do not skip checking due to some
condition.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
