Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit9816e2d

Browse files
author
Amit Kapila
committed
Invalidate relcache when changing REPLICA IDENTITY index.
When changing REPLICA IDENTITY INDEX to another one, the target table'srelcache was not being invalidated. This leads to skipping update/deleteoperations during apply on the subscriber side as the columns required tosearch corresponding rows won't get logged.Author: Tang Haiying, Hou ZhijieReviewed-by: Euler Taveira, Amit KapilaBackpatch-through: 10Discussion:https://postgr.es/m/OS0PR01MB61133CA11630DAE45BC6AD95FB939@OS0PR01MB6113.jpnprd01.prod.outlook.com
1 parent523adcc commit9816e2d

File tree

2 files changed

+91
-1
lines changed

2 files changed

+91
-1
lines changed

‎src/backend/commands/tablecmds.c

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -14411,6 +14411,12 @@ relation_mark_replica_identity(Relation rel, char ri_type, Oid indexOid,
1441114411
CatalogTupleUpdate(pg_index, &pg_index_tuple->t_self, pg_index_tuple);
1441214412
InvokeObjectPostAlterHookArg(IndexRelationId, thisIndexOid, 0,
1441314413
InvalidOid, is_internal);
14414+
/*
14415+
* Invalidate the relcache for the table, so that after we commit
14416+
* all sessions will refresh the table's replica identity index
14417+
* before attempting any UPDATE or DELETE on the table.
14418+
*/
14419+
CacheInvalidateRelcache(rel);
1441414420
}
1441514421
heap_freetuple(pg_index_tuple);
1441614422
}

‎src/test/subscription/t/100_bugs.pl

Lines changed: 85 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@
33
use warnings;
44
use PostgresNode;
55
use TestLib;
6-
use Test::Moretests=>3;
6+
use Test::Moretests=>5;
77

88
# Bug #15114
99

@@ -100,3 +100,87 @@
100100
);
101101

102102
$node_publisher->stop('fast');
103+
104+
# https://postgr.es/m/OS0PR01MB61133CA11630DAE45BC6AD95FB939%40OS0PR01MB6113.jpnprd01.prod.outlook.com
105+
106+
# The bug was that when changing the REPLICA IDENTITY INDEX to another one, the
107+
# target table's relcache was not being invalidated. This leads to skipping
108+
# UPDATE/DELETE operations during apply on the subscriber side as the columns
109+
# required to search corresponding rows won't get logged.
110+
$node_publisher = get_new_node('publisher3');
111+
$node_publisher->init(allows_streaming=>'logical');
112+
$node_publisher->start;
113+
114+
$node_subscriber = get_new_node('subscriber3');
115+
$node_subscriber->init(allows_streaming=>'logical');
116+
$node_subscriber->start;
117+
118+
$node_publisher->safe_psql('postgres',
119+
"CREATE TABLE tab_replidentity_index(a int not null, b int not null)");
120+
$node_publisher->safe_psql('postgres',
121+
"CREATE UNIQUE INDEX idx_replidentity_index_a ON tab_replidentity_index(a)"
122+
);
123+
$node_publisher->safe_psql('postgres',
124+
"CREATE UNIQUE INDEX idx_replidentity_index_b ON tab_replidentity_index(b)"
125+
);
126+
127+
# use index idx_replidentity_index_a as REPLICA IDENTITY on publisher.
128+
$node_publisher->safe_psql('postgres',
129+
"ALTER TABLE tab_replidentity_index REPLICA IDENTITY USING INDEX idx_replidentity_index_a"
130+
);
131+
132+
$node_publisher->safe_psql('postgres',
133+
"INSERT INTO tab_replidentity_index VALUES(1, 1),(2, 2)");
134+
135+
$node_subscriber->safe_psql('postgres',
136+
"CREATE TABLE tab_replidentity_index(a int not null, b int not null)");
137+
$node_subscriber->safe_psql('postgres',
138+
"CREATE UNIQUE INDEX idx_replidentity_index_a ON tab_replidentity_index(a)"
139+
);
140+
$node_subscriber->safe_psql('postgres',
141+
"CREATE UNIQUE INDEX idx_replidentity_index_b ON tab_replidentity_index(b)"
142+
);
143+
# use index idx_replidentity_index_b as REPLICA IDENTITY on subscriber because
144+
# it reflects the future scenario we are testing: changing REPLICA IDENTITY
145+
# INDEX.
146+
$node_subscriber->safe_psql('postgres',
147+
"ALTER TABLE tab_replidentity_index REPLICA IDENTITY USING INDEX idx_replidentity_index_b"
148+
);
149+
150+
$publisher_connstr =$node_publisher->connstr .' dbname=postgres';
151+
$node_publisher->safe_psql('postgres',
152+
"CREATE PUBLICATION tap_pub FOR TABLE tab_replidentity_index");
153+
$node_subscriber->safe_psql('postgres',
154+
"CREATE SUBSCRIPTION tap_sub CONNECTION '$publisher_connstr' PUBLICATION tap_pub"
155+
);
156+
157+
$node_publisher->wait_for_catchup('tap_sub');
158+
159+
# Also wait for initial table sync to finish
160+
my$synced_query =
161+
"SELECT count(1) = 0 FROM pg_subscription_rel WHERE srsubstate NOT IN ('s', 'r');";
162+
$node_subscriber->poll_query_until('postgres',$synced_query)
163+
ordie"Timed out while waiting for subscriber to synchronize data";
164+
165+
is($node_subscriber->safe_psql(
166+
'postgres',"SELECT * FROM tab_replidentity_index"),
167+
qq(1|1
168+
2|2),
169+
"check initial data on subscriber");
170+
171+
# Set REPLICA IDENTITY to idx_replidentity_index_b on publisher, then run UPDATE and DELETE.
172+
$node_publisher->safe_psql(
173+
'postgres',qq[
174+
ALTER TABLE tab_replidentity_index REPLICA IDENTITY USING INDEX idx_replidentity_index_b;
175+
UPDATE tab_replidentity_index SET a = -a WHERE a = 1;
176+
DELETE FROM tab_replidentity_index WHERE a = 2;
177+
]);
178+
179+
$node_publisher->wait_for_catchup('tap_sub');
180+
is($node_subscriber->safe_psql(
181+
'postgres',"SELECT * FROM tab_replidentity_index"),
182+
qq(-1|1),
183+
"update works with REPLICA IDENTITY");
184+
185+
$node_publisher->stop('fast');
186+
$node_subscriber->stop('fast');

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp