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(at)gmail(dot)com> wrote:

> On Fri, Dec 10, 2021 at 7:39 AM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)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
>