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.96) (envelope-from ) id 1wD8Nr-002dke-1P for pgsql-general@arkaria.postgresql.org; Wed, 15 Apr 2026 22:06:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wD8Nq-002RyF-2F for pgsql-general@arkaria.postgresql.org; Wed, 15 Apr 2026 22:06:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wD8Nq-002Ry6-0v for pgsql-general@lists.postgresql.org; Wed, 15 Apr 2026 22:06:54 +0000 Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wD8No-00000001ITm-07i7 for pgsql-general@lists.postgresql.org; Wed, 15 Apr 2026 22:06:53 +0000 Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-5a40502e63bso2413404e87.0 for ; Wed, 15 Apr 2026 15:06:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776290805; cv=none; d=google.com; s=arc-20240605; b=SrG9OlOuWgYqTkR+fTcFIbcG9TdokE3a/ntzpStx0ZRTewQM6uUGUc0cRuH1hqASHi AqEpzbyZERJI/ysYyi0JOoU5noi2vyz+SVcWgMYLjt3Jz1JF0v38rG45Jss6RhIyFfrn ACQ5vntxV178MPHYmdSZlOHPOlR2B0imdScQEEz4iAvizJ8nNiW4672yp33kGXRFw2NV XGLzCtqsB7d0L9C/ZeZBb624u576XMP4o2tdAKM5SCFThelL8QQ6NBvPjiuqdB9dabaZ h0/gqk4B4WptjepGyXJPvJ2Yxo/NpWl7z9M/UxnxuxqA1OzwspuQ5dFHRZ1+HRbIvT/M 5PJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=WItgy2mEYtiF6HJyl+CdvxBqxQVvUUZ1QFkgH8fpnhU=; fh=4rCG0PM8n0FOokGy8sSWDJpgPdCgp6yIXcpABJ7tUh0=; b=Jx2drRmq25bKuYNPCx4rn9tsPKPF941VNJw4fzYV7QjmeGVqzhNmxJvObyaMk12Fkp jbiKt71T85gYt89+uWO+RrP5WifdizciqNU1xaqtAaesF/HbQ7lItov0cSM8s9f25W25 s6Jv3vyycUwXNSxiy0CXEoJn156yx9VInCUQ7TpgdjglbVYWR5HuuNqhQQhPwMaWsjpv PYw2yIzJr/v445KkWN1Z/vo7Co7HjUsJhvnYsKjzRYykUhBJlUOyogvkVwuCvLtP9d/3 zoTO5COT49YMdBRm2q0RVGtRXtzgRZawYJtvhAIeEkGdV50eFI45LHja+vp74K+rBP4v ZcqA==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776290805; x=1776895605; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=WItgy2mEYtiF6HJyl+CdvxBqxQVvUUZ1QFkgH8fpnhU=; b=gHoFSx9DvOsqvYY9xJn5eq8Qav0H+gHocz65/a6InZFFBT5ym/KUDrEUlVBF/tHRBw 1GQuG856HD97F11J2FJMvZoYY3sSpFv3M3iLXi61//ZPe+qu1c9PjH1BBqiE5oozj9U9 dJKpMYGCnQHeeaH3Jx8t7SKohOMM0NHcm/d4hvPhJDpqu20PNE0IsgNa7e8JEq2TMRLC 2a8b8RbYVb2eA3HIuVM0+GEGDde3XTKqh/iuGddg8MsBDgIwNMnVor7Dp518CScnW4/J LKYwWMZ/qYJ9X6nw9sv16mOnyGtl0u94w1qGranFfQVGXCUWLj2g7X7aK2CiuQcwcWKj eu3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776290805; x=1776895605; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WItgy2mEYtiF6HJyl+CdvxBqxQVvUUZ1QFkgH8fpnhU=; b=CbrTczR0C0kjp19Sov5CGeRYkl69OdpfsdVPiHTt5zqf9um18KTVFqTGvcEhaveAWZ XFp/oGSUqzsxOFq0HhdWBRd+SkgiLnj87AKq1B0oJKP352VdU+YYsaJ7KMNgMJyEgcLx eHYMVuRGtOhk1+NVABsCEEKe6ynNsq403EGgux0pqrKzY18fvHMZUelzMo8BfSPQjV/j +HanVslb72OPofVDtdQSlSGayIl8tBu+A7ppw1zaiz6BKuK64yZmESAWC3Y2ujNKMl1w 3+hYjwllZ4b4aFN7A2Lkv2PkRkDCTvjLXGLzmDtqUM7OiTSvAOky5mzzc+BlBgCaar2M 2kpQ== X-Gm-Message-State: AOJu0Yw9qqJhI1MJguN+40eFuVhkn7FvL4/HLbegigvU570fr4QMF8ks 9gE0ogMUrNdKlRKMyQIW33p8gVQILQEzodIAyPUFELOr3mtQgH+CTmLRNPp5IcS4/fkPmZbpMQ8 tvJHjlgs/ranOo3RBZcfMQFk0uTx281k6lnea X-Gm-Gg: AeBDies1L9bFTlgoT/IYP4Tz12kBXsscXHhv/5PrXkS1C3VwKy7WmRpeOd9j1B0hA60 YNVoc7QlKKXejHXokhQMluUGLosOa3JhFHSJqVMb9gB3wiQMdzymVzVyE9uwJzm1a/hlmdg9hLu Iliwy1CBTS9faXk81Dg7mM6SVe2JXyzUpjOIVUP99gKkqphMADJ37F2618M3xPu7CflGpROAbwE 3LSlQPI3Xid5rZ6VcwK8TtTv2eDBUmkPFd3/gFXnbeucR/beSYqvQuFP4OTisLWgf4Hox71KqEX BfbZPPrk8amYtmtgog== X-Received: by 2002:a05:6512:304d:b0:5a1:3d7f:8f99 with SMTP id 2adb3069b0e04-5a3efb3ca48mr8232155e87.33.1776290805122; Wed, 15 Apr 2026 15:06:45 -0700 (PDT) MIME-Version: 1.0 From: Jatinder Singh Sandhu Date: Wed, 15 Apr 2026 18:06:33 -0400 X-Gm-Features: AQROBzBDwFOw33NTJ4B69GLcD13OHgaGtLcRDGvCiVO_1CrmcAe7kZhXmj9PQDA Message-ID: Subject: physical replication compatibilty To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000750bc8064f86eee5" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000750bc8064f86eee5 Content-Type: text/plain; charset="UTF-8" Dear PostgreSQL Community, I am currently planning a major version upgrade from PostgreSQL 16 to PostgreSQL 17. I have three node patroni cluster. While I am aware that logical replication is the standard approach for cross-version migrations, I am curious about the feasibility of physical streaming replication in this specific scenario. Specifically, I would like to clarify: 1. Is physical streaming replication backward compatible between these two major versions? 2. Since many data files remain consistent between versions, is there any supported method to leverage physical block-level replication to minimize the initial data synchronization time before a cutover? I understand that WAL formats and system catalogs typically change between major releases, but I wanted to confirm if there are any modern workarounds or "late-binding" techniques available in the v17 ecosystem. Thank you for your time and expertise. Best regards, --000000000000750bc8064f86eee5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear PostgreSQL Community,
I am currently planning a major version = upgrade from PostgreSQL 16 to PostgreSQL 17. I have three node=C2=A0patroni= cluster. While I am aware that logical replication = is the standard approach for cross-version migrations, I am curious about t= he feasibility of physical streaming replication in this specific scenario.=
Sp= ecifically, I would like to clarify:
  1. Is physical= streaming replication backward compatible between these two major versions= ?
  2. Since many data files remain consistent between versions, is there = any supported method to leverage physical block-level replication to minimi= ze the initial data synchronization time before a cutover?
=
I unders= tand that WAL formats and system catalogs typically change between major re= leases, but I wanted to confirm if there are any modern workarounds or &quo= t;late-binding" techniques available in the v17 ecosystem.
Thank you for = your time and expertise.
Best regards,
--000000000000750bc8064f86eee5--