Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade
От | Dilip Kumar |
---|---|
Тема | Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade |
Дата | |
Msg-id | CAFiTN-uaaaFeZq1ubckuTozWQj+A=dTUaEgdtDN5F-LNyjRfrA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Ответы |
Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade
|
Список | pgsql-hackers |
On Fri, Jun 7, 2024 at 11:57 AM Matthias van de Meent <boekewurm+postgres@gmail.com> wrote: > > On Fri, 7 Jun 2024 at 07:18, Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > On Wed, Jun 5, 2024 at 10:59 PM Matthias van de Meent > > <boekewurm+postgres@gmail.com> wrote: > >> > >> On Wed, 5 Jun 2024 at 18:47, Ranier Vilela <ranier.vf@gmail.com> wrote: > >>> > >>> Why not use it too, if not binary_upgrade? > >> > >> Because in the normal case (not during binary_upgrade) you don't want > >> to have to generate 2 checkpoints for every created database, > >> especially not when your shared buffers are large. Checkpoints' costs > >> scale approximately linearly with the size of shared buffers, so being > >> able to skip those checkpoints (with strategy=WAL_LOG) will save a lot > >> of performance in the systems where this performance impact matters > >> most. > > > > I agree with you that we introduced the WAL_LOG strategy to avoid > > these force checkpoints. However, in binary upgrade cases where no > > operations are happening in the system, the FILE_COPY strategy should > > be faster. > > While you would be correct if there were no operations happening in > the system, during binary upgrade we're still actively modifying > catalogs; and this is done with potentially many concurrent jobs. I > think it's not unlikely that this would impact performance. Maybe, but generally, long checkpoints are problematic because they involve a lot of I/O, which hampers overall system performance. However, in the case of a binary upgrade, the concurrent operations are only performing a schema restore, not a real data restore. Therefore, it shouldn't have a significant impact, and the checkpoints should also not do a lot of I/O during binary upgrade, right? > Now that I think about it, arguably, we shouldn't need to run > checkpoints during binary upgrade for the FILE_COPY strategy after > we've restored the template1 database and created a checkpoint after > that: All other databases use template1 as their template database, > and the checkpoint is there mostly to guarantee the FS knows about all > changes in the template database before we task it with copying the > template database over to our new database, so the protections we get > from more checkpoints are practically useless. > If such a change were implemented (i.e. no checkpoints for FILE_COPY > in binary upgrade, with a single manual checkpoint after restoring > template1 in create_new_objects) I think most of my concerns with this > patch would be alleviated. Yeah, I think that's a valid point. The second checkpoint is to ensure that the XLOG_DBASE_CREATE_FILE_COPY never gets replayed. However, for binary upgrades, we don't need that guarantee because a checkpoint will be performed during shutdown at the end of the upgrade anyway. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления:
Предыдущее
От: jian heДата:
Сообщение: using __func__ to locate and distinguish some error messages
Следующее
От: Alvaro HerreraДата:
Сообщение: Re: using __func__ to locate and distinguish some error messages