Re: SKIP LOCKED DATA (work in progress)
От | Heikki Linnakangas |
---|---|
Тема | Re: SKIP LOCKED DATA (work in progress) |
Дата | |
Msg-id | 53FB6FCD.1030405@vmware.com обсуждение исходный текст |
Ответ на | Re: SKIP LOCKED DATA (work in progress) (Thomas Munro <munro@ip9.org>) |
Список | pgsql-hackers |
On 07/31/2014 12:29 AM, Thomas Munro wrote: > On 29 July 2014 02:35, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: >> David Rowley wrote: >> >>> I've also been looking at the isolation tests and I see that you've added a >>> series of tests for NOWAIT. I was wondering why you did that as that's >>> really existing code, probably if you thought the tests were a bit thin >>> around NOWAIT then maybe that should be a separate patch? >> >> The isolation tester is new so we don't have nearly enough tests for it. >> Adding more meaningful tests is good even if they're unrelated to the >> patch at hand. > > Here are my isolation tests for NOWAIT as a separate patch, > independent of SKIP LOCKED. They cover the tuple lock, regular row > lock and multixact row lock cases. Thanks, committed. > I guess this might be called white > box testing, since it usese knowledge of how to construct schedules > that hit the three interesting code paths that trigger the error, even > though you can't see from the output why the error was raised in each > case without extra instrumentation (though it did cross my mind that > it could be interesting at the very least for testing if the error > message were different in each case). Yeah, seems reasonable. This kind of tests might become obsolete in the future if the internals change a lot, so that e.g. we don't use multixids anymore. But even if that happens, there's little harm in keeping the tests, and meanwhile it's good to have coverage of these cases. - Heikki
В списке pgsql-hackers по дате отправления: