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 | 20180228061229.GG1476@paquier.xyz обсуждение исходный текст |
| Ответ на | 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 mistakenlycopies data files
|
| Список | pgsql-hackers |
On Mon, Feb 26, 2018 at 06:24:02PM +0900, Michael Paquier wrote: > 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. So I would propose to just do that later. I have looked a second time at your patch, attached is the set of tests I have run: - With assertions enabled, I see pg_rewind failing on an assertion as mentioned upthread. - With assertion disabled (look at rewind_logs.log as generated by the script attached), then all the files from the tablespace are copied with all the file chunks fetched at the second phase of the rewind. - With the patch, both the assertion and the handling of tablespace files are fixed. Again, in the logs produced by the script you would see that tablespace files are not completely copied anymore, and that only portions of them are. I have one small comment though. The comment block at the beginning of isRelDataFile() refers to "pg_tblspc/<tblspc oid>/PG_9.4_201403261/". Could you switch that to "pg_tblspc/<tblspc oid>/<tblspc version>"? That's not directly the fault of your patch, but as long as we are on it.. So I am marking this as ready for committer. Thanks for the report, Tsunakawa-san! -- Michael
Вложения
В списке pgsql-hackers по дате отправления: