Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
От | Keisuke Kuroda |
---|---|
Тема | Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables |
Дата | |
Msg-id | CANDwggLtCjuLyhSbR-uJBect09io4uwKGREqOyhYZeq--G8kEw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
Hi Amit, > I don't have a patch for this idea but you can refer [1] > (v25-0002-Issue-individual-invalidations-with-wal_level-lo) to see > what I was trying to say about registering the invalidations in the > form of ReorderBufferChange. We have something along the lines of what > I described above in that patch but we have removed it because we need > all the invalidations to be accumulated to handle aborts and we don't > want two different mechanisms to store invalidations. Thanks, I read the patch (v25-0002-Issue-individual-invalidations-with-wal_level-lo) and the review. I understand the following. * In v25-0002, there were two different mechanisms, XLOG_XACT_INVALIDATIONS (ReorderBufferAddInvalidation) and XLOG_INVALIDATIONS (ReorderBufferAddInvalidations). * After a review, XLOG_XACT_INVALIDATIONS was implemented to generate all invalidation messages. I'm going to write a patch that looks like the following. * Add the process of collecting invalidation to XLOG_XACT_INVALIDATIONS in the form of ReorderBufferChange. * Invalidation is executed in case REORDER_BUFFER_CHANGE_INVALIDATION. Best Regards, -- Keisuke Kuroda NTT Software Innovation Center keisuke.kuroda.3862@gmail.com
В списке pgsql-hackers по дате отправления: