Re: [bug fix] pg_rewind takes long time because it mistakenly copiesdata files
От | Michael Paquier |
---|---|
Тема | Re: [bug fix] pg_rewind takes long time because it mistakenly copiesdata files |
Дата | |
Msg-id | 20180226092402.GH6927@paquier.xyz обсуждение исходный текст |
Ответ на | RE: [bug fix] pg_rewind takes long time because it mistakenlycopies data files ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
Ответы |
Re: [bug fix] pg_rewind takes long time because it mistakenly copiesdata files
|
Список | pgsql-hackers |
On Mon, Feb 26, 2018 at 08:13:02AM +0000, Tsunakawa, Takayuki wrote: > 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/ Sure. >> 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. Anything like that would be work only for HEAD I think as that's a bit of refactoring. And indeed it could give you a good introduction to the TAP facility. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: