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 1sZROQ-0011TP-LY for pgsql-general@arkaria.postgresql.org; Thu, 01 Aug 2024 08:42:38 +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 1sZROP-005MqI-17 for pgsql-general@arkaria.postgresql.org; Thu, 01 Aug 2024 08:42:37 +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 1sZROO-005Mq8-Ks for pgsql-general@lists.postgresql.org; Thu, 01 Aug 2024 08:42:36 +0000 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sZROM-002ZmD-0W for pgsql-general@lists.postgresql.org; Thu, 01 Aug 2024 08:42:35 +0000 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-52f04c29588so11585762e87.3 for ; Thu, 01 Aug 2024 01:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=attendium.com; s=google; t=1722501751; x=1723106551; darn=lists.postgresql.org; h=to:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=Vens+KmkuC8TgY8eQ++ehv1Dk6UnBt4g9GC54A3U5PM=; b=gOtf19JgrVuLS2hrjaU0xW9f4eEfgXzPdrXEuBeHdXYhVRh4dLRLJ0lHQ+YTWAeEkV jndJrRyJCe8JFzssRMW4wtU9I6VsMKseFQm7OuGsbE6tjG6e/g0U1ZxKlh1BXvytJ3js pojplpEeP0aTgYPr0ykufsgqSYKHr5Lklc+ho= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722501751; x=1723106551; h=to:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Vens+KmkuC8TgY8eQ++ehv1Dk6UnBt4g9GC54A3U5PM=; b=xOhyvpIk+qyL3dpLQok+Gw+oOxgmNFpUP8KDmkWbmrr128DJ0JktH1ieuDQNFM7Oj5 f+OcxZnbEWu1OURvtzlMJrKgZlMZ61ENHOZmWD0XfIelYtR2dTeUodiDek9ai1UktQ32 ZxlkiaROKhoc85GaZoxbm4SG4uzY03TYsZrN2Tb1IaajRyZjTnbiFw2HlVCDJS8x8Bvy NHe/vss0u6ufRS33KgBTXiAXiaMFR3x5ldC1POa0+ozVgocQj3Ft+C8Zyes1F7ajGvQX yGZ6sN9a2r/mYyIV2wZOGGS0YYpWhoiLYCrOdtWJOpPJ0wzaotoJbC51dQeXjUY7ieAn mO0Q== X-Gm-Message-State: AOJu0Yxjn08ZWKlfAOvWbGgEuiesCEB0f9+rJBkl/zaFqOrBt+R4Obiy a4KhnXKA49hYHwVWpxLFAVrXuqTWAaozskzkdye7shRzza8cGSCxLi0wJ7HHZBEAgwRIdZJ+YrZ 5 X-Google-Smtp-Source: AGHT+IFeZHrSABlbnFN6Kjy6PjaDUKuc43KaMUcgZNQLW68tInYs9TOTxu7ivGvi7+6TpccGHaLT4A== X-Received: by 2002:a05:6512:3f08:b0:52e:9c0a:3514 with SMTP id 2adb3069b0e04-530b61ebfb2mr1050187e87.44.1722501751191; Thu, 01 Aug 2024 01:42:31 -0700 (PDT) Received: from smtpclient.apple ([2001:1ba8:1464:8100:dd99:9a29:17e2:ff08]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-52fd5bc42d6sm2517687e87.45.2024.08.01.01.42.30 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Aug 2024 01:42:30 -0700 (PDT) From: Piotr Andreassen Blasiak Content-Type: multipart/alternative; boundary="Apple-Mail=_D92D36A2-3874-4295-9926-0E6E850FD575" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Logical replication slots on slaves/replicas? Message-Id: Date: Thu, 1 Aug 2024 10:42:20 +0200 To: pgsql-general@lists.postgresql.org 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=_D92D36A2-3874-4295-9926-0E6E850FD575 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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=_D92D36A2-3874-4295-9926-0E6E850FD575 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii 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=_D92D36A2-3874-4295-9926-0E6E850FD575--