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
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 |