Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup andpg_receivewal --endpos
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup andpg_receivewal --endpos |
Дата | |
Msg-id | d687ec42-1da4-c6b9-61d7-ea5fd47e131a@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup andpg_receivewal --endpos
|
Список | pgsql-hackers |
On 6/9/17 02:08, Michael Paquier wrote: > On Wed, Jun 7, 2017 at 9:20 AM, Michael Paquier > <michael.paquier@gmail.com> wrote: >> While it is possible to tackle some of those issues independently, >> like pg_basebackup stuff, it seems to me that it would be helpful to >> make the tests more deterministic by having an --endpos option for >> pg_receivewal, similarly to what exists already in pg_recvlogical. >> >> Thoughts? > > I have just played with that, and attached is a patch to implement the > so-said option with a basic set of tests, increasing code coverage of > pg_receivewal.c from 15% to 60%. I'll park that in the next CF of > September. Looks like a good idea. A couple of thoughts: - I think the tests should be written in the style of $node->command_fails instead of just command_fails. At least, that's how it's done in the pg_basebackup tests. - I think the tests will fail if libz support is not built. Again, pg_basebackup doesn't have tests for that. So maybe omit that and address it later. - The variable exit_on_stop seems redundant with time_to_abort. They do the same thing, so maybe your patch could reuse it. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: