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 1sZWeC-001aKI-H8 for pgsql-general@arkaria.postgresql.org; Thu, 01 Aug 2024 14:19:16 +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 1sZWeA-00AQN3-E5 for pgsql-general@arkaria.postgresql.org; Thu, 01 Aug 2024 14:19:14 +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.94.2) (envelope-from ) id 1sZWeA-00AQMt-0N for pgsql-general@lists.postgresql.org; Thu, 01 Aug 2024 14:19:14 +0000 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sZWe7-002cL2-Du for pgsql-general@lists.postgresql.org; Thu, 01 Aug 2024 14:19:13 +0000 Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3683178b226so3348513f8f.1 for ; Thu, 01 Aug 2024 07:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=attendium.com; s=google; t=1722521949; x=1723126749; darn=lists.postgresql.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=/iOkzqJ+5Kfgba59HxKr1mIWH/CkpxiUm6u1xDQeT2Q=; b=oy1q7LoWuJjRsK1wYtPJn/CBeR5k/GKXhE5k9GHwFgFdDHDCbvPgI5WWIqXe7F4nFK Ea9EzjW2VbNe2jjlEIBecPIWIQ6nLo3YaXO5OxcmmBTWAaMVxq33DT5I1yD+NG/Y/o2J o2/qQNqJitSxbvtALdi50hGtvmSWjbJ470/Yg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722521949; x=1723126749; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/iOkzqJ+5Kfgba59HxKr1mIWH/CkpxiUm6u1xDQeT2Q=; b=YnNjJ09XCtc226m5JG1bZsheXset20cTNk4w092OZ7lbCDElMVm7fL97Hh4rOcDkTW OOYnb+HgNAsgIhAx5nbZ8IXJk4597l38xyJdjUdT2gv+DYeggkgT9rb1nLRTHmFUIAHG SIfqr+y7HYeMWS6TgrqUO5hg8t+Zlja2t4GsfhC8Yo27pL+3LCMmPtIzd7He9OjUMsge lM/UaoAILQVeqdCeXZVvKjIMnCUjzxwfrZmDJHS+pBFkaLLDMO4zYFJpc3xQzrI4XFbJ JrznwsyU3/msD8GwavrotN+3Lda+JWXJPkmbKz07rAwBFPv8TX9Yva2z/WrzvlEI4v0V R+Xw== X-Gm-Message-State: AOJu0Ywt5axobQV3Izsmi0FL/XzORPU00IPqROOTh4qHSt1EkAhjRLSZ W+b5q/ExUZUVCzvUtkcJdjUoeK6xtp1UTjQxZbAL+OTJq+qlamUtBrr7ujyXC7E= X-Google-Smtp-Source: AGHT+IGkkHN2lhLUnbbCytTr2S/ss1DGSakn4Nw9h9uUi9Hucjbwo3ScobKIFGMM18sZ5GKg2cOi6w== X-Received: by 2002:a5d:54c8:0:b0:368:5d2:9e58 with SMTP id ffacd0b85a97d-36bbbffc9f0mr29484f8f.0.1722521948651; Thu, 01 Aug 2024 07:19:08 -0700 (PDT) Received: from smtpclient.apple (ec2-54-78-216-196.eu-west-1.compute.amazonaws.com. [54.78.216.196]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-36b36857fd1sm19552833f8f.69.2024.08.01.07.19.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Aug 2024 07:19:08 -0700 (PDT) From: Piotr Andreassen Blasiak Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B8E0C44D-42F7-456E-B50C-F88287DB4B9E" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: Logical replication slots on slaves/replicas? Date: Thu, 1 Aug 2024 16:18:54 +0200 In-Reply-To: Cc: pgsql-general@lists.postgresql.org To: =?utf-8?Q?Torsten_F=C3=B6rtsch?= References: X-Mailer: Apple Mail (2.3774.300.61.1.2) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Apple-Mail=_B8E0C44D-42F7-456E-B50C-F88287DB4B9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That=C2=B4s a great point. Thank you. Piotr Andreassen Blasiak > On 1 Aug 2024, at 12:03, Torsten F=C3=B6rtsch = wrote: >=20 > A COMMIT record in the WAL has an LSN. I don't know much about = debezuim but wal2json can give you this LSN. Then there is this = function, pg_last_wal_replay_lsn(). I think you could run it on the = replica to see if you are after the point of commit. If you are, you = should be able to see the changes made by the transaction. >=20 > BTW, I am sure I can construct a situation where you see your = transaction in the logical wal stream before it becomes visible on the = master. In particular, this is possible with a sync replication setup. = So, I would not trust to always be able to see the transaction on the = master as soon as it is reported committed in the wal stream. >=20 > All the best, > Torsten >=20 > On Thu, Aug 1, 2024 at 10:42=E2=80=AFAM Piotr Andreassen Blasiak = > wrote: >> Hi, >>=20 >> I know that currently logical replication slots are available only = for primary servers. Is there any plan to add this feature to read = slaves as well? My problem is this: >>=20 >> I want to use debezium to stream changes from postgresql. But, if I = stream changes from the master I can not query my read slaves for = related data to these changes - I need to always query the master which = is not scalable. So either I need a way to be able to know when the = change has been propagated to my read replica so that I can reliably = query it, or I am hoping I can simply read all the changes from the read = replica which will mean it is already up to date when I query it. >>=20 >> Piotr Andreassen Blasiak >>=20 >>=20 >>=20 >>=20 --Apple-Mail=_B8E0C44D-42F7-456E-B50C-F88287DB4B9E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That=C2=B4s a = great point. Thank you.

Piotr Andreassen = Blasiak




On 1 Aug 2024, at 12:03, Torsten = F=C3=B6rtsch <tfoertsch123@gmail.com> wrote:

A COMMIT = record in the WAL has an LSN. I don't know much about debezuim but = wal2json can give you this LSN. Then there is this = function, pg_last_wal_replay_lsn(). I think you could run it on the = replica to see if you are after the point of commit. If you are, you = should be able to see the changes made by the = transaction.

BTW, I am sure I can construct a = situation where you see your transaction in the logical wal stream = before it becomes visible on the master. In particular, this is possible = with a sync replication setup. So, I would not trust to always be able = to see the transaction on the master as soon as it is reported committed = in the wal stream.

All the = best,
Torsten

On Thu, Aug 1, 2024 at 10:42=E2=80=AFAM = Piotr Andreassen Blasiak <piotr@attendium.com> = wrote:
Hi,

I know = that currently logical replication slots are available only for primary = servers. Is there any plan to add this feature to read slaves as well? = My problem is this:

I want to use debezium to = stream changes from postgresql. But, if I stream changes from the master = I can not query my read slaves for related data to these changes - I = need to always query the master which is not scalable. So either I need = a way to be able to know when the change has been propagated to my read = replica so that I can reliably query it, or I am hoping I can simply = read all the changes from the read replica which will mean it is already = up to date when I query it.

Piotr Andreassen = Blasiak





= --Apple-Mail=_B8E0C44D-42F7-456E-B50C-F88287DB4B9E--