Re: [Patch] Optimize dropping of relation buffers using dlist
От | Amit Kapila |
---|---|
Тема | Re: [Patch] Optimize dropping of relation buffers using dlist |
Дата | |
Msg-id | CAA4eK1Ld1vV8q-bvR_dCEAJNLA2kfx2g5GwYTtxVcp6u0h7T7g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Patch] Optimize dropping of relation buffers using dlist (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
RE: [Patch] Optimize dropping of relation buffers using dlist
|
Список | pgsql-hackers |
On Wed, Sep 2, 2020 at 9:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapila16@gmail.com> writes: > > Even if the relation is locked, background processes like checkpointer > > can still touch the relation which might cause problems. Consider a > > case where we extend the relation but didn't flush the newly added > > pages. Now during truncate operation, checkpointer can still flush > > those pages which can cause trouble for truncate. But, I think in the > > recovery path such cases won't cause a problem. > > I wouldn't count on that staying true ... > > https://www.postgresql.org/message-id/CA+hUKGJ8NRsqgkZEnsnRc2MFROBV-jCnacbYvtpptK2A9YYp9Q@mail.gmail.com > I don't think that proposal will matter after commit c5315f4f44 because we are caching the size/blocks for recovery while doing extend (smgrextend). In the above scenario, we would have cached the blocks which will be used at later point of time. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: