Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t1MdG-00FwBF-5k for pgsql-general@arkaria.postgresql.org; Thu, 17 Oct 2024 09:17:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t1MdE-001x9D-Ce for pgsql-general@arkaria.postgresql.org; Thu, 17 Oct 2024 09:17:20 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t1MdE-001x94-0u for pgsql-general@lists.postgresql.org; Thu, 17 Oct 2024 09:17:20 +0000 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t1Md8-001KkZ-Pp for pgsql-general@lists.postgresql.org; Thu, 17 Oct 2024 09:17:18 +0000 Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a99f3a5a44cso80440066b.3 for ; Thu, 17 Oct 2024 02:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kleczek.org; s=google; t=1729156633; x=1729761433; darn=lists.postgresql.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KaO3rh3Pgh45DaLWklplMMw2jXbo7GTSosH125dQguo=; b=EqFiKmg7tbL1wto4j/DqmaZQ0LJgGCIEPTGpGrqIF1VVJuE+XtrI9GP9Dwm1+gtTBY m62teLAUSq517s0FSpT2OcOebOq57NOI8P5n7YJ9Q7iSz3d6TUs0QdOkkRC6Lkvldbkl Vj4+9OWecptjHQhJyiU6TO3+ZSwOKFNQtMyXA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729156633; x=1729761433; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KaO3rh3Pgh45DaLWklplMMw2jXbo7GTSosH125dQguo=; b=wQ9NDsD9DStUHeOtUmnbmnKpG5FZFH/w2ncGbyPhd7HM43PxgqbIHp9paWfP+xoErc VxZ9rxMNWOL4Js3rQm3vDlq0dLQoOJvcBPFw2m4TuFiUYoRDj2EyEzsyHeSGDp0XfCOE Ao7E/vFpdRprvj65z1sf0gv7cCeCIi0u6bWUEXrODHaKbAxgSe+2osjQoIC6QS/hPwiL m68O7kxvVQK9bkt7RqXGRVLQZ762VOswxOgXY/8jwZybVv0viS4Q8k8fYgAlQuWRTJmI rAQ33G6hgl19JXf8XN+wdgNePmbSGECKYFoSIZO5Kvrr3VUdpI9nBTwSOvuCd46Lzlc1 8Z7g== X-Forwarded-Encrypted: i=1; AJvYcCUfTsLZiLg52kTiczvfCjbQreDB/m9z2I6zmTG6WxnjTOyOqEohWuF9Il+RTfZXCj1Xzskml7Qk31Avkwku@lists.postgresql.org X-Gm-Message-State: AOJu0Yyy7XoPFeuU9KisP0Vg3n5r/FXrF9WmjTKz3KSpA3EWMPj/yChQ Lx611AERUE8dyXS3Lcj3BQbW+jBXhmIqyE9Y9k47lZzaQ/Z8rqhdCdqj5DUFTWI= X-Google-Smtp-Source: AGHT+IGvGjwlhc4KhqPX3t3LLrs0OdCra7WmTlbwxn2uKBklPgHlfuDL0reVokkoHe9KdvWUSTt6Ww== X-Received: by 2002:a17:907:2d9e:b0:a99:fd61:c9a9 with SMTP id a640c23a62f3a-a9a34e0b3f3mr599547666b.52.1729156632871; Thu, 17 Oct 2024 02:17:12 -0700 (PDT) Received: from smtpclient.apple (b15.kleczek.org. [185.20.172.182]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9a29740e1fsm269175766b.51.2024.10.17.02.17.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Oct 2024 02:17:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: Logical replication disabled, recovery not possible because of 1 large transaction with schema changes? From: =?utf-8?Q?Micha=C5=82_K=C5=82eczek?= In-Reply-To: Date: Thu, 17 Oct 2024 11:16:41 +0200 Cc: Muhammad Usman Khan , pgsql-general Content-Transfer-Encoding: quoted-printable Message-Id: <657111A5-7475-4198-B8FD-83E87D628F5B@kleczek.org> References: To: Koen De Groote X-Mailer: Apple Mail (2.3776.700.51) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 17 Oct 2024, at 11:07, Koen De Groote wrote: >=20 > Hello Muhammad, >=20 > The problem with my scenario is the changes are written as a single = transaction, with a BEGIN and COMMIT. In that transaction, there are = first inserts, then a schema change, and then inserts on the new schema. I guess until logical replication of DDL is available you=E2=80=99re out = of luck. The best you can do is to have a separate table for recording and = replaying schema changes. Create triggers that perform actual DDL operations based on DML in this = table. Publish this table on the publisher in the same publication as the = tables affected by the DDL. On the subscriber side it is the same - just make the trigger is marked = as ENABLE REPLICA TRIGGER or ENABLE ALWAYS TRIGGER. Kind regards, Micha=C5=82