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

Commit354a1f8

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 parent1b098da commit354a1f8

File tree

2 files changed

+89
-1
lines changed

2 files changed

+89
-1
lines changed

‎src/backend/commands/tablecmds.c

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -15488,6 +15488,12 @@ relation_mark_replica_identity(Relation rel, char ri_type, Oid indexOid,
1548815488
CatalogTupleUpdate(pg_index, &pg_index_tuple->t_self, pg_index_tuple);
1548915489
InvokeObjectPostAlterHookArg(IndexRelationId, thisIndexOid, 0,
1549015490
InvalidOid, is_internal);
15491+
/*
15492+
* Invalidate the relcache for the table, so that after we commit
15493+
* all sessions will refresh the table's replica identity index
15494+
* before attempting any UPDATE or DELETE on the table.
15495+
*/
15496+
CacheInvalidateRelcache(rel);
1549115497
}
1549215498
heap_freetuple(pg_index_tuple);
1549315499
}

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

Lines changed: 83 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66
use warnings;
77
use PostgreSQL::Test::Cluster;
88
use PostgreSQL::Test::Utils;
9-
use Test::Moretests=>5;
9+
use Test::Moretests=>7;
1010

1111
# Bug #15114
1212

@@ -224,3 +224,85 @@
224224
$node_pub->stop('fast');
225225
$node_pub_sub->stop('fast');
226226
$node_sub->stop('fast');
227+
228+
# https://postgr.es/m/OS0PR01MB61133CA11630DAE45BC6AD95FB939%40OS0PR01MB6113.jpnprd01.prod.outlook.com
229+
230+
# The bug was that when changing the REPLICA IDENTITY INDEX to another one, the
231+
# target table's relcache was not being invalidated. This leads to skipping
232+
# UPDATE/DELETE operations during apply on the subscriber side as the columns
233+
# required to search corresponding rows won't get logged.
234+
$node_publisher = PostgreSQL::Test::Cluster->new('publisher3');
235+
$node_publisher->init(allows_streaming=>'logical');
236+
$node_publisher->start;
237+
238+
$node_subscriber = PostgreSQL::Test::Cluster->new('subscriber3');
239+
$node_subscriber->init(allows_streaming=>'logical');
240+
$node_subscriber->start;
241+
242+
$node_publisher->safe_psql('postgres',
243+
"CREATE TABLE tab_replidentity_index(a int not null, b int not null)");
244+
$node_publisher->safe_psql('postgres',
245+
"CREATE UNIQUE INDEX idx_replidentity_index_a ON tab_replidentity_index(a)"
246+
);
247+
$node_publisher->safe_psql('postgres',
248+
"CREATE UNIQUE INDEX idx_replidentity_index_b ON tab_replidentity_index(b)"
249+
);
250+
251+
# use index idx_replidentity_index_a as REPLICA IDENTITY on publisher.
252+
$node_publisher->safe_psql('postgres',
253+
"ALTER TABLE tab_replidentity_index REPLICA IDENTITY USING INDEX idx_replidentity_index_a"
254+
);
255+
256+
$node_publisher->safe_psql('postgres',
257+
"INSERT INTO tab_replidentity_index VALUES(1, 1),(2, 2)");
258+
259+
$node_subscriber->safe_psql('postgres',
260+
"CREATE TABLE tab_replidentity_index(a int not null, b int not null)");
261+
$node_subscriber->safe_psql('postgres',
262+
"CREATE UNIQUE INDEX idx_replidentity_index_a ON tab_replidentity_index(a)"
263+
);
264+
$node_subscriber->safe_psql('postgres',
265+
"CREATE UNIQUE INDEX idx_replidentity_index_b ON tab_replidentity_index(b)"
266+
);
267+
# use index idx_replidentity_index_b as REPLICA IDENTITY on subscriber because
268+
# it reflects the future scenario we are testing: changing REPLICA IDENTITY
269+
# INDEX.
270+
$node_subscriber->safe_psql('postgres',
271+
"ALTER TABLE tab_replidentity_index REPLICA IDENTITY USING INDEX idx_replidentity_index_b"
272+
);
273+
274+
$publisher_connstr =$node_publisher->connstr .' dbname=postgres';
275+
$node_publisher->safe_psql('postgres',
276+
"CREATE PUBLICATION tap_pub FOR TABLE tab_replidentity_index");
277+
$node_subscriber->safe_psql('postgres',
278+
"CREATE SUBSCRIPTION tap_sub CONNECTION '$publisher_connstr' PUBLICATION tap_pub"
279+
);
280+
281+
$node_publisher->wait_for_catchup('tap_sub');
282+
283+
# Also wait for initial table sync to finish
284+
$node_subscriber->poll_query_until('postgres',$synced_query)
285+
ordie"Timed out while waiting for subscriber to synchronize data";
286+
287+
is($node_subscriber->safe_psql(
288+
'postgres',"SELECT * FROM tab_replidentity_index"),
289+
qq(1|1
290+
2|2),
291+
"check initial data on subscriber");
292+
293+
# Set REPLICA IDENTITY to idx_replidentity_index_b on publisher, then run UPDATE and DELETE.
294+
$node_publisher->safe_psql(
295+
'postgres',qq[
296+
ALTER TABLE tab_replidentity_index REPLICA IDENTITY USING INDEX idx_replidentity_index_b;
297+
UPDATE tab_replidentity_index SET a = -a WHERE a = 1;
298+
DELETE FROM tab_replidentity_index WHERE a = 2;
299+
]);
300+
301+
$node_publisher->wait_for_catchup('tap_sub');
302+
is($node_subscriber->safe_psql(
303+
'postgres',"SELECT * FROM tab_replidentity_index"),
304+
qq(-1|1),
305+
"update works with REPLICA IDENTITY");
306+
307+
$node_publisher->stop('fast');
308+
$node_subscriber->stop('fast');

0 commit comments

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