Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Keisuke Kuroda <keisuke.kuroda.3862@gmail.com>
From: Keisuke Kuroda <keisuke.kuroda.3862@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-09-30T05:39:03Z
Lists: 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
Commits
-
Execute invalidation messages for each XLOG_XACT_INVALIDATIONS message
- d7eb52d7181d 14.0 landed
-
WAL Log invalidations at command end with wal_level=logical.
- c55040ccd017 14.0 cited