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 1sJZ0b-005aG2-9J for pgsql-general@arkaria.postgresql.org; Tue, 18 Jun 2024 13:36:25 +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 1sJZ0Y-00DL0J-JC for pgsql-general@arkaria.postgresql.org; Tue, 18 Jun 2024 13:36:23 +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 1sJYxK-00DDhd-Fv for pgsql-general@lists.postgresql.org; Tue, 18 Jun 2024 13:33:03 +0000 Received: from mail-oa1-x31.google.com ([2001:4860:4864:20::31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sJYxE-001urW-HU for pgsql-general@lists.postgresql.org; Tue, 18 Jun 2024 13:33:02 +0000 Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-25957dfd971so1070982fac.0 for ; Tue, 18 Jun 2024 06:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718717575; x=1719322375; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=AlV3mjy+m7kRwNVD3fOqubw4Nqwd7vhVqiM8OgMh6Fw=; b=Bwj8z88gOVAfNl2MHwuQrWuvysZ70wdSZuvQTeOqchKB6l9NlLY6v42X6JSCuFzwkY FlXzraIk9PrbE8uBt1P+kxcaf80TIAsypDXjGFmpZy/dyC4g4A4IhAz6uGnJ/amzPKAp Eywmf0RZpdv8ACcmE646wwJZa4pG5AeLNZ1McnYQ69qnPpuKJEgLM5Yv4Rs26fx4dUGi UU2TsifjBVfJqJ1SyH3VCRVyl7CAuF15IH5VRWyv91E/nIf0OA/CLIoi1Nag7IF+obW1 H+4JRI47z9TIGCGpcuK0rBlcXngjZ4lqu2FK6v4skcuDrEsXjrL1QBek33cb86VRsrvW pxlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718717575; x=1719322375; h=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=AlV3mjy+m7kRwNVD3fOqubw4Nqwd7vhVqiM8OgMh6Fw=; b=PZ6Bmk2QI/JXkHixli532u0GiONQUqZ8dxZhohNXm146JUiavymPx+DpmhvFqHtJq9 mqblVpiyYx5cNEJWFMUL7jOmcy499BgzTbdiufI3SZaI110EFShYXmvYNHbONSSx8xh8 EQTlRQFEuZ/kzHlsxD8EPgFt6B9Cy4Ssa4zL2LpwWxjEOS85rp/CV9oGf9z5SLkQAaX2 VMDYmVt0KlUzqah8+IJxuueYJlOs/8BrcU67dhq+WSmcKN/FYIKRZNaq7P1jBw5F8hNt 6K0q9ZjTNgxyaYSoj2il6Y8KdbeFTIRH5+WbyRLEqS2X4VeeoOAtwQs6nzgSQgUNZBKa muTg== X-Gm-Message-State: AOJu0YzmhVKQYuEtdL8u71bL0ZxBFw4AeeI4T2mZKK9InMVBLSdpqy7V Hvauid1HWQS06kbt21KQJlhV3y8jn5az4VR7wsQ64AUeufn03iUbrgREd/S8QQ6QMB/vHiSbCR9 jUhc2rjmKZL/0W8+bibkthSbA3/nJwA== X-Google-Smtp-Source: AGHT+IGlNh43dwJ5N3OVuixQxmhTu9jqsm6KuDA/49jcLF+p7AMTJHHmMknqPIsi9hTXMFNdMLoxr/SyqPYgNL6jMHQ= X-Received: by 2002:a05:6870:f71c:b0:220:873d:dbcc with SMTP id 586e51a60fabf-25842b7b550mr15194220fac.49.1718717575389; Tue, 18 Jun 2024 06:32:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Tue, 18 Jun 2024 09:32:43 -0400 Message-ID: Subject: Re: Monitoring logical replication To: pgsql-general list Content-Type: multipart/mixed; boundary="0000000000008d0405061b2a1ecf" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000008d0405061b2a1ecf Content-Type: multipart/alternative; boundary="0000000000008d0403061b2a1ecd" --0000000000008d0403061b2a1ecd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 18, 2024 at 5:03=E2=80=AFAM Shaheed Haque wrote: > Hi all, > > Is there an "official" pairing of LSN values on the publication and > subscription sides that should be used to track the delta between the two > systems? I ask because Google is full of different pairs being used. I > tried to identify the highest level interface points exposed, i.e. what i= s > documented on > https://www.postgresql.org/docs/current/replication-origins.html, the > pg_stat_subscription table, the pg_stat_publication table and the > pg_current_wal_lsn() function on the publisher, but these seem to be bare= ly > used. > The attached scripts (whose guts I took from a Stack Exchange post) might be a good starting point. It certainly works for physical replication! > P.S. On a related note, I see a (stalled?) discussion on providing LSN -> > timestamp conversion > = , > I'd just like to say that something like that would be very useful. > Out of curiosity, how does that work? Is an instance's initial LSN really based on Epoch? --0000000000008d0403061b2a1ecd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 18, 2024 at 5:03=E2=80=AFAM S= haheed Haque <shaheedhaque@gma= il.com> wrote:
Hi all,
Is there an "official" pairing of LSN values on the = publication and subscription sides that should be used to track the delta b= etween the two systems? I ask because Google is full of different pairs bei= ng used. I tried to identify the highest level interface points exposed, i.= e. what is documented on https://www.postgresql.org/doc= s/current/replication-origins.html,=C2=A0the pg_stat_subscription table= , the pg_stat_publication table and the=20 pg_current_wal_lsn() function on the publisher, but these seem to be barely= used.

The attached scripts (wh= ose guts I took from a Stack Exchange post) might be a good starting point.= =C2=A0 It certainly works for physical replication!
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
P.S.= On a related note, I see a (stalled?) discussion on providing LSN -> timestamp conversion, I'd just like to say= that something like that would be very useful.
=C2=A0
Out of curiosity, how does that work?=C2=A0 Is an instan= ce's initial LSN really based on Epoch?
--0000000000008d0403061b2a1ecd-- --0000000000008d0405061b2a1ecf Content-Type: text/x-sh; charset="US-ASCII"; name="physical_backlog.sh" Content-Disposition: attachment; filename="physical_backlog.sh" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lxkfxq8d0 IyEvYmluL2Jhc2gNCg0KcmVhZG9ubHkgUHJpbWU9Zm9vMS5leGFtcGxlLmNvbQ0KcmVhZG9ubHkg UmVwbGljYT1mb28yLmV4YW1wbGUuY29tDQoNCndhbF9sb2NhdGlvbl90b182NGJpdHMoKQ0Kew0K ICAgIGxvY2FsIGlkPSIkezElJS8qfSINCiAgICBsb2NhbCBvZmZzZXQ9IiR7MSMjKi99Ig0KICAg IGVjaG8gJCgoMHhGRjAwMDAwMCAqIDB4JGlkICsgMHgkb2Zmc2V0KSkNCn0NCg0KZGVjbGFyZSBQ cmltZV9TU0UgUHJpbWVfTFNODQpkZWNsYXJlIFNlY29uZF9TU0UgU2Vjb25kX1JlY3ZfTFNOIFNl Y29uZF9SZXBsX0xTTg0KDQpJRlM9JCdcdCcgcmVhZCAtciBQcmltZV9MU04gXA0KICAgICAgICA8 PDwkKHBzcWwgLS1ob3N0PSRQcmltZSAtWEF0IC1GJCdcdCcgXA0KICAgICAgICAgICAgICAgIC1j ICJzZWxlY3QgcGdfY3VycmVudF93YWxfbHNuKCk7IikNCklGUz0kJ1x0JyByZWFkIC1yIFNlY29u ZF9UaW1lc3RhbXAgU2Vjb25kX1JlY3ZfTFNOIFNlY29uZF9SZXBsX0xTTiBcDQogICAgICAgIDw8 PCQocHNxbCAtLWhvc3Q9JFJlcGxpY2EgLVhBdCAtRiQnXHQnIFwNCiAgICAgICAgICAgICAgICAt YyAic2VsZWN0IHBnX2xhc3Rfd2FsX3JlY2VpdmVfbHNuKCkNCiAgICAgICAgICAgICAgICAgICAg ICAgICwgcGdfbGFzdF93YWxfcmVwbGF5X2xzbigpOyIpDQoNClByaW1lX1NTRT0kKGRhdGUgKyIl cy4lTiIgLWQgIiRQcmltZV9UaW1lc3RhbXAiKQ0KU2Vjb25kX1NTRT0kKGRhdGUgKyIlcy4lTiIg LWQgIiRTZWNvbmRfVGltZXN0YW1wIikNCmRlY2xhcmUgUXVlcnlfTGFnPSQoZWNobyAiJFNlY29u ZF9TU0UgLSAkUHJpbWVfU1NFIiB8IGJjIC1sKQ0KDQpwcmludGYgIlF1ZXJ5IExhZzogJWZcbiIg JFF1ZXJ5X0xhZw0KDQplY2hvICJMU046Ig0KcHJpbnRmICIgIFByaW1lOiAgICAgICAgICAgID0g JXNcbiIgJFByaW1lX0xTTg0KcHJpbnRmICIgIFJlcGxpY2EgUmVjZWl2ZWQ6ID0gJXNcbiIgJFNl Y29uZF9SZWN2X0xTTg0KcHJpbnRmICIgIFJlcGxpY2EgUmVwbGF5ZWQ6ID0gJXNcbiIgJFNlY29u ZF9SZXBsX0xTTg0KDQpkZWNsYXJlIC1pIFByaW1lX0J5dGVzPSQod2FsX2xvY2F0aW9uX3RvXzY0 Yml0cyAkUHJpbWVfTFNOKQ0KZGVjbGFyZSAtaSBTZWNvbmRfUmVjdl9CeXRlcz0kKHdhbF9sb2Nh dGlvbl90b182NGJpdHMgJFNlY29uZF9SZWN2X0xTTikNCmRlY2xhcmUgLWkgU2Vjb25kX1JlcGxf Qnl0ZXM9JCh3YWxfbG9jYXRpb25fdG9fNjRiaXRzICRTZWNvbmRfUmVwbF9MU04pDQoNCmVjaG8g IkJhY2tsb2cgQnl0ZXM6Ig0KcHJpbnRmICIgIFJlY2VpdmVkID0gJScxOGRcbiIgJChlY2hvICIo JFByaW1lX0J5dGVzIC0gJFNlY29uZF9SZWN2X0J5dGVzKSIgfCBiYyAtbCkNCnByaW50ZiAiICBS ZXBsYXllZCA9ICUnMThkXG4iICQoZWNobyAiKCRQcmltZV9CeXRlcyAtICRTZWNvbmRfUmVwbF9C eXRlcykiIHwgYmMgLWwp --0000000000008d0405061b2a1ecf--