Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints

+       /*
+        * If the relation is from the default tablespace then we need to
+        * create it in the destinations db's default tablespace.
Otherwise,
+        * we need to create in the same tablespace as it is in the source
+        * database.
+        */

This comment looks a bit confusing to me especially because when we say
destination db's default tablespace people may think of pg_default
tablespace (at least I think so). Basically what you are trying to say here
- "If the relation exists in the same tablespace as the src database, then
in the destination db also it should be the same or something like that.. "
So, why not put it that way instead of referring to it as the default
tablespace. It's just my view. If you disagree you can ignore it.

--

+       else if (src_dboid == dst_dboid)
+           continue;
+       else
+           dstrnode.spcNode = srcrnode.spcNode;;

There is an extra semicolon here.

--
With Regards,
Ashutosh Sharma.


On Sun, Dec 12, 2021 at 1:39 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:

> On Fri, Dec 10, 2021 at 7:39 AM Ashutosh Sharma <ashu.coek88@gmail.com>
> wrote:
> >>
> >> Logfile Snippet:
> >> 2021-12-09 17:49:18.110 +04 [18151] PANIC:  could not fsync file
> "base/116398/116400": No such file or directory
> >> 2021-12-09 17:49:19.105 +04 [18150] LOG:  checkpointer process (PID
> 18151) was terminated by signal 6: Aborted
> >> 2021-12-09 17:49:19.105 +04 [18150] LOG:  terminating any other active
> server processes
> >
> >
> > This is different from the issue you raised earlier. As Dilip said, we
> need to unregister sync requests for files that got successfully copied to
> the target database, but the overall alter database statement failed. We
> are doing this when the database is created successfully, but not when it
> fails.
> > Probably doing the same inside the cleanup function
> movedb_failure_callback() should fix the problem.
>
> Correct, I have done this cleanup, apart from this we have dropped the
> fsyc request in create database failure case as well and also need to
> drop buffer in error case of creatdb as well as movedb.  I have also
> fixed the other issue for which you gave the patch (a bit differently)
> basically, in case of movedb the source and destination dboid are same
> so we don't need an additional parameter and also readjusted the
> conditions to avoid nested if.
>
> --
> Regards,
> Dilip Kumar
> EnterpriseDB: http://www.enterprisedb.com
>