Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>,
Keisuke Kuroda <keisuke.kuroda.3862@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-10-09T04:35:53Z
Lists: pgsql-hackers
On Fri, Oct 9, 2020 at 8:40 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, Oct 8, 2020 at 2:34 PM Simon Riggs <simon@2ndquadrant.com> wrote: > > > > On Thu, 8 Oct 2020 at 09:47, Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > > > This script will wait 10 seconds after INSERT exits > > > > before executing TRUNCATE, please wait for it to run. > > > > Has this been tested with anything other than the one test case? > > > > It would be good to know how the patch handles a transaction that > > contains many aborted subtransactions that contain invals. > > > > Are you thinking from the angle of performance or functionality? I > don't see how this patch can impact either of those. Basically, it > will not execute any extra invalidations then it is executing without > the patch for aborted subtransactions. Can you please explain in a bit > more detail about your fear? > > Having said that, I think it would be a good idea to test the scenario > you mentioned to ensure that we have not broken anything unknowingly. Yeah, even I feel that nothing should impact in this area because on abort we are anyway executing all the invalidations and we will continue to do so with the patch as well. I will test this scenario to ensure nothing is broken. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.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