Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pD3py-0003mR-97 for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Jan 2023 13:29:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pD3px-0000tx-1r for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Jan 2023 13:29:45 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pD3pw-0000sj-Of for pgsql-hackers@lists.postgresql.org; Wed, 04 Jan 2023 13:29:44 +0000 Received: from mail-yw1-x1135.google.com ([2607:f8b0:4864:20::1135]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pD3pu-0008Fv-Bv for pgsql-hackers@lists.postgresql.org; Wed, 04 Jan 2023 13:29:43 +0000 Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-476e643d1d5so360027457b3.1 for ; Wed, 04 Jan 2023 05:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HkaTb3XYKRF9ifMB2V+XBqUz9QxkvF+DbXUhXVWC4QQ=; b=KMGN5SYUFXslVy2CfugYUYUf+QygCX4wZKCc7pSGmae1CkHBdO2g/rcKFE2fiKPL8Y yaC8jckNH5Tug/k77oTYxRlFTftuCVIuQAeOq9W1FPUiGD0RdR1sty/eRw/ExKkc8ywx nLW6cSiK/bs8sNA3tzOUE9grge5y10H9eqBwgdCRGBKxjIPNz8mFXy2eowXtOAPHuhPS YTf3JkhSrK5aoeemx/n6GaykVgG82AuDBOcWtUInvrsde7Fp8Uv/2BjEi7dyJf2UjF52 VyHUHQ9nHaBuyKRUdoDXiYNx0d04DboauAviAy93Ab1JhKMLufHh4T5Jzxwmxr5fg6cN /t9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HkaTb3XYKRF9ifMB2V+XBqUz9QxkvF+DbXUhXVWC4QQ=; b=S0qsoVVQ4HMNxWRcYbyHOseyWMSPnvO/IckGWIJVXI55omTflOBk88Hyt3MuEiZk0M PPg1YzixLQ6y+xoOD2hME4R1sWUlKeKGpKsDzq0/FecCaA79UpaX8tDjyIHKwLcB9sr6 P5Bucnzx0Q9Pu6Dwsv9bGOloxhC35iA0xZ2QHcBhVyVo0vGApsXPv1cnqYAPobYJ8F4O t10TtULQQHL5BBYojnBg3tGu3VIlt+qf9zqoStIdUpVlN3elpNJIx1Ln59ocxxltkCKx gNA9l+y1zTDtsFYm67EoFnt32opr/hDzLaFMYEh/fv1oB58Wm2K6lt4CsWb15YUFtBzO 2J9w== X-Gm-Message-State: AFqh2kqEef0pi0rL3zA5gc3nYkZ29hBb7deGJiympdupsSDSm+VrjktS iFXCpYkvxN6J5+Jw13AhwNUSC8TQVpOv+Gfrh/E= X-Google-Smtp-Source: AMrXdXs+5qZGtOruBVT5Yk70CfoM0QxjIMS2dA97y/wdex/lGTGWjCwXEJVG4XnS5X0abby5ihy8U9H9OSbelUZ1Yes= X-Received: by 2002:a81:a109:0:b0:4a4:557:14bd with SMTP id y9-20020a81a109000000b004a4055714bdmr1503136ywg.323.1672838981566; Wed, 04 Jan 2023 05:29:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Wed, 4 Jan 2023 18:59:24 +0530 Message-ID: Subject: Re: Perform streaming logical transactions by background workers and parallel apply To: Amit Kapila Cc: "houzj.fnst@fujitsu.com" , Masahiko Sawada , "wangw.fnst@fujitsu.com" , Peter Smith , "shiy.fnst@fujitsu.com" , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jan 4, 2023 at 6:40 PM Amit Kapila wrote: > > On Wed, Jan 4, 2023 at 4:52 PM Dilip Kumar wrote: > > > > 2. > > + * Since the database structure (schema of subscription tables, constraints, > > + * etc.) of the publisher and subscriber could be different, applying > > + * transactions in parallel mode on the subscriber side can cause some > > + * deadlocks that do not occur on the publisher side. > > > > I think this paragraph needs to be rephrased a bit. It is saying that > > some deadlock can occur on subscribers which did not occur on the > > publisher. I think what it should be conveying is that the deadlock > > can occur due to concurrently applying the conflicting/dependent > > transactions which are not conflicting/dependent on the publisher due > > to . Because if we create the same schema on the > > publisher it might not have ended up in a deadlock instead it would > > have been executed in sequence (due to lock waiting). So the main > > point we are conveying is that the transaction which was independent > > of each other on the publisher could be dependent on the subscriber > > and they can end up in deadlock due to parallel apply. > > > > How about changing it to: "We have a risk of deadlock due to > parallelly applying the transactions that were independent on the > publisher side but became dependent on the subscriber side due to the > different database structures (like schema of subscription tables, > constraints, etc.) on each side. I think this looks good to me. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com