Re: [HACKERS] TAP tests take a long time
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] TAP tests take a long time |
Дата | |
Msg-id | CAB7nPqRz1=jvq3_NWvWkzBibq2TZMROSk7Wvo4ukT7JHJ5anOg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] TAP tests take a long time (Craig Ringer <craig.ringer@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] TAP tests take a long time
Re: [HACKERS] TAP tests take a long time |
Список | pgsql-hackers |
On Wed, Apr 12, 2017 at 9:12 AM, Craig Ringer <craig.ringer@2ndquadrant.com> wrote: > Well, you can get a lot of information on timings in crake's latest > builds for example, or nightjar's. > > Here's an interesting fact: almost all the time taken up in the scripts > test set seems to be consumed in running initdb over and over. > > Is it worth adding an init(cache => 1) option to PostgresNode, where we > stash an initdb'd db in tmp_check/ and just do a simple fs copy of it ? This looks like a good idea to me, but I don't like much the idea of an option in the init() routine as that's hard to maintain. It would make sense to me to be able to override the initialization with an environment variable instead, or just make it the default and get the base image stored in tmp_install/. Base backups are out of scope though. > It reduces our coverage of initdb only incredibly slightly - all that repeat > runs will do is help find very uncommon intermittent failures. And we rerun > the buildfarm all the time so it's not like there's a shortage of initdb > runs anyway. initdb is always run with the same set of options when init() is called, so this is not something to worry about. And tests inherent to initdb should happen in src/bin/initdb. > We should also have a debug --no-fsync option for initdb, or maybe allow it > to take -o options to pass to child postgres so we can pass fsync=off . That's an idea as well... -- Michael
В списке pgsql-hackers по дате отправления: