Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
От | Dilip Kumar |
---|---|
Тема | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |
Дата | |
Msg-id | CAFiTN-vzju2gVvL4yzhu0dWvR3nOgyYnOp-CVJg=PgOHSpytGw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Fri, Feb 18, 2022 at 4:30 AM Robert Haas <robertmhaas@gmail.com> wrote: > > > > This thread is long. Could you summarize what lead you to consider other > > approaches (e.g. looking in the filesystem for relfilenodes) as not feasible / > > too ugly / ...? > > I don't think it's infeasible to look at the filesystem for files and > just copy whatever files we find. It's a plausible alternate design. I > just don't like it as well. I think that relying on the filesystem > contents to tell us what's going on is kind of hacky. The only > technical issue I see there is that the WAL logging might require more > kludgery, since that mechanism is kind of intertwined with > shared_buffers. You'd have to get the right block references into the > WAL record, and you have to make sure that checkpoints don't move the > redo pointer at an inopportune moment. Actually based on the previous discussion, I also tried to write the POC with the file system scanning approach to identify the relation to be copied seet patch 0007 in this thread [1]. And later we identified one issue [2], i.e. while scanning directly the disk file we will only know the relfilenode but we can not identify the relation oid that means we can not lock the relation. Now, I am not saying that there is no way to work around that issue but that was also one of the reasons for not pursuing that approach. [1] https://www.postgresql.org/message-id/CAFiTN-v1KYsVAhq_fOWFa27LZiw9uK4n4cz5XmQJxJpsVcfq1w%40mail.gmail.com [2] https://www.postgresql.org/message-id/CAFiTN-v%3DU58by_BeiZruNhykxk1q9XUxF%2BqLzD2LZAsEn2EBkg%40mail.gmail.com -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: