RE: [bug fix] pg_rewind takes long time because it mistakenlycopies data files
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: [bug fix] pg_rewind takes long time because it mistakenlycopies data files |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1F8D6E9E@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: [bug fix] pg_rewind takes long time because it mistakenly copiesdata files (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: [bug fix] pg_rewind takes long time because it mistakenly copiesdata files
|
Список | pgsql-hackers |
From: Michael Paquier [mailto:michael@paquier.xyz] > Your patch is able to fix that. I have also checked that after diverging > the promoted server with more data and inserting data on the old primary > then the correct set of blocks from the tablespace is fetched as well by > pg_rewind. This patch also behaves correctly when creating a new relation > on the promoted server as it copies the whole relation. In short your patch > looks good to me. How quick, I was surprised. Thank you so much! I'd be glad if you could be the reviewer in CF: https://commitfest.postgresql.org/17/1542/ > Creating a test case for this patch would be nice, however this needs a > bit of work so as the tablespace map can be used with pg_basebackup and > PostgresNode.pm (or use raw pg_basebackup commands in pg_rewind tests): > - PostgresNode::init_from_backup needs to be able to understand extra > options given by caller for pg_basebackup. > - RewindTest::create_standby should be extended with extra arguments given > for previous extension. > :( That sounds difficult from your way of saying... but this may be a good opportunity to look into the TAP tests. Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: