Re: SQL:2011 application time

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Paul Jungwirth <pj(at)illuminatedcomputing(dot)com>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SQL:2011 application time
Date: 2024-11-13 10:11:37
Message-ID: 6dc196d4-8853-49d7-8dd3-e391058451c1@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

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.

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message wenhui qiu 2024-11-13 10:33:17 Re: New GUC autovacuum_max_threshold ?
Previous Message Frédéric Yhuel 2024-11-13 10:03:25 Re: New GUC autovacuum_max_threshold ?