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

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
Date: 2021-09-06 08:59:38
Message-ID: CAFiTN-uKE-wvdsxUAacVD7Qf4i35PrQF_3+6Cs0S1O-8QMk7Jw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 6, 2021 at 11:17 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote

>
> Okay, that makes sense. Infact for using the shared buffers for the
> destination database's relation we don't even have the locking issue,
> because that database is not yet accessible to anyone right?
>

Based on all these discussions I am planning to change the design as below,

- FlushDatabaseBuffers().

- Scan the database directory under each tablespace and prepare a
tablespace-wise relfilenode list, along with this we will remember the
persistent level as well based on the presence of INITFORK.

- Next, copy each relfilenode to the destination, while copying for the
source relation directly use the smgrread whereas for the destination
relation use bufmgr. The main reasons for not using the bufmgr for the
source relations are a) We can avoid acquiring a special-purpose lock on
the relation b) We are copying from the template database so in most of the
cases there might not be many dirty buffers for that database so there is
no real need for using the shared buffers.

Any objections to the above design?

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2021-09-06 09:25:39 Re: ORDER BY pushdowns seem broken in postgres_fdw
Previous Message Peter Eisentraut 2021-09-06 08:30:06 Re: Fix pkg-config file for static linking