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 1tBdax-0058ZF-AF for pgsql-hackers@arkaria.postgresql.org; Thu, 14 Nov 2024 17:25:26 +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 1tBdas-005zaA-Qj for pgsql-hackers@arkaria.postgresql.org; Thu, 14 Nov 2024 17:25:23 +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 1tBdas-005za2-CZ for pgsql-hackers@lists.postgresql.org; Thu, 14 Nov 2024 17:25:23 +0000 Received: from mail-pg1-x52f.google.com ([2607:f8b0:4864:20::52f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tBdao-001w35-HD for pgsql-hackers@lists.postgresql.org; Thu, 14 Nov 2024 17:25:22 +0000 Received: by mail-pg1-x52f.google.com with SMTP id 41be03b00d2f7-7d4f85766f0so671832a12.2 for ; Thu, 14 Nov 2024 09:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=illuminatedcomputing-com.20230601.gappssmtp.com; s=20230601; t=1731605116; x=1732209916; darn=lists.postgresql.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hNAM21eVm9w7hJO3cxu5nB1N5+sDrO6RJ6N5P9pfH1g=; b=H61wrEuy0gGgKE+u9g6JFBeKGXm1gcs3z9n+tk6C/SGuTJXGekQ/fs58tO+keAutq0 Za3pxIPGJ8RjOG5hZK1/cBfWacK6hfgIlfzcu0vmUid8XO2NLx7gVEx/ANg+KCgnjufc BoaGlO3+5Sdi0bX5yFMqQFTyvqThkYjVDg2LkF3stLEPgUPhyLu/L0bWd2FeP5iDA0LJ 4RS6sqZDfjxfJbb7YN54BMg8H5YvFFYnMHvEMSVWFHW/rAk+bnlOQC13zsHpTFca6bdr FzG550BZMU49wiuQS+doPUwntp3rHUcxiKITxQImHjFbfk5/BY8xgJKbxCj7Pzd+8Gqn YyHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731605116; x=1732209916; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hNAM21eVm9w7hJO3cxu5nB1N5+sDrO6RJ6N5P9pfH1g=; b=NY4bWET7lUSSYGLzIA19E36iA4Ofh1HbRMYM+pkxuBqIwGTRV0pZCgBhidRoMRkoxa THGbldHbfW6nI8Dv6w/zWhrbb5bQMDWNxMdRhoQGN2j4Sc6rLaT8ok1mOmOe0BeKoccT sX7YS9CaOPfZ7DBEVcBS2558/JqIsjRtmQTvgJkw69Oks6632xfiVLUy6MhxVhmvm42t HbRgXisLyhOd6TTq9zSTPYLfBw2T5jUchdxuDjrv5jIP5fVOKrCMhkSS2RXQDGREtsG8 rrql5kkoR/4KQrc1zigeu4csY64XjbnEhAAQoBCDficKloTCTe8B3goO6jMFy/wJpyrV Hlwg== X-Forwarded-Encrypted: i=1; AJvYcCXM4bJE1Db+cXR7tyWBFhKsOulFEUbzhKCWyTbeS9xo50qmf60Ce1DbkK1cbw5E8tJmefpP0RoAsUzS8WI2@lists.postgresql.org X-Gm-Message-State: AOJu0YzPhG8bcO/ui+RiDAAhq8uxFDWG1zUy81+78TQ5My5qw6+aNvwV GYzO8Ux0ABMUty6xC+dZvEt7QSSWzxVSs/+1Jl+m0o8KYUSv5ZwG5r4g7S05S7k= X-Google-Smtp-Source: AGHT+IEOSOGVW8KG5KTdW1kOAgeN67NAPNOil3VhDdX0FNxkGcnIm9delseOKLTtvLhSUejgVB4SWQ== X-Received: by 2002:a05:6a20:729e:b0:1d9:69ca:6b24 with SMTP id adf61e73a8af0-1dc703abd27mr8733685637.23.1731605116476; Thu, 14 Nov 2024 09:25:16 -0800 (PST) Received: from [192.168.2.139] ([50.39.255.79]) by smtp.googlemail.com with ESMTPSA id 41be03b00d2f7-7f8b37f8640sm1345199a12.49.2024.11.14.09.25.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Nov 2024 09:25:15 -0800 (PST) Message-ID: Date: Thu, 14 Nov 2024 09:25:15 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: SQL:2011 application time To: Peter Eisentraut Cc: jian he , PostgreSQL Hackers References: <30dc3561-d7ab-42be-a1c5-096643423590@illuminatedcomputing.com> <73d09e24-b6b9-4c89-8c0a-8842ca0f81f9@illuminatedcomputing.com> <081aa43c-3a97-4bd5-a498-ba02e0a7570d@illuminatedcomputing.com> <54390149-11d6-4f52-bbe8-f69832ceb3bd@eisentraut.org> <9b7cb814-c78c-489f-85b2-32be4398647f@illuminatedcomputing.com> <95c6d49b-7d60-4ad0-820c-e00ae1b2a3d4@illuminatedcomputing.com> <57ea0668-5205-426e-b934-efc89f2186c2@illuminatedcomputing.com> <6dc196d4-8853-49d7-8dd3-e391058451c1@eisentraut.org> Content-Language: en-US From: Paul Jungwirth In-Reply-To: <6dc196d4-8853-49d7-8dd3-e391058451c1@eisentraut.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 11/13/24 02:11, Peter Eisentraut wrote: > I have committed the documentation patches > > v43-0001-Add-WITHOUT-OVERLAPS-and-PERIOD-to-ALTER-TABLE-r.patch > v43-0002-Update-conexclop-docs-for-WITHOUT-OVERLAPS.patch Thanks! > For the logical replication fixes > > v43-0003-Fix-logical-replication-for-temporal-tables.patch > > can you summarize what the issues currently are?  Is it currently broken, or just not working as > well as it could? > > AFAICT, there might be two separate issues.  One is that you can't use a temporal index as replica > identity, because ALTER TABLE rejects it.  The other is that a subscriber fails to make use of a > replica identity index, because it uses the wrong strategy numbers. Correct, there are two issues this commit fixes: On the publisher side: You can use REPLICA IDENTITY DEFAULT with a temporal PK/UNIQUE index. There is no validation step, and sending the changes works fine. But REPLICA IDENTITY USING INDEX fails because the validation step rejects the non-btree index. Then on the subscriber side, we are not applying changes correctly, because we assume the strategy numbers are btree numbers. > This conditional is really hard to understand: > > +       /* > +        * The AM must support uniqueness, and the index must in fact be unique. > +        * If we have a WITHOUT OVERLAPS constraint (identified by uniqueness + > +        * exclusion), we can use that too. > +        */ > +       if ((!indexRel->rd_indam->amcanunique || > +               !indexRel->rd_index->indisunique) && > +               !(indexRel->rd_index->indisunique && indexRel->rd_index->indisexclusion)) > > Why can we have a indisunique index when the AM is not amcanunique?  Are we using the fields wrong? > > -       return get_equal_strategy_number_for_am(am); > +       /* For GiST indexes we need to ask the opclass what strategy number to use. */ > +       if (am == GIST_AM_OID) > +               return GistTranslateStratnum(opclass, RTEqualStrategyNumber); > +       else > +               return get_equal_strategy_number_for_am(am); > > This code should probably be pushed into get_equal_strategy_number_for_am().  That function already > has a switch based on index AM OIDs.  Also, there are other callers of > get_equal_strategy_number_for_am(), which also might want to become aware of GiST support. > > For the new test file, remember to add it to src/test/subscription/meson.build. > > Also, maybe add a introductory comment in the test file to describe generally what it's trying to test. Okay, I'll make these changes and re-send the patch. Yours, -- Paul ~{:-) pj@illuminatedcomputing.com