Re: logical decoding : exceeded maxAllocatedDescs for .spill files
От | Amit Khandekar |
---|---|
Тема | Re: logical decoding : exceeded maxAllocatedDescs for .spill files |
Дата | |
Msg-id | CAJ3gD9diTB8rqyUWo=jZrSQxvW7o-gGaO6uoF5racneH3+FYOg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: logical decoding : exceeded maxAllocatedDescs for .spill files (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: logical decoding : exceeded maxAllocatedDescs for .spill files
|
Список | pgsql-hackers |
On Sun, 5 Jan 2020 at 00:21, Noah Misch <noah@leadboat.com> wrote: > The buildfarm client can capture stack traces, but it currently doesn't do so > for TAP test suites (search the client code for get_stack_trace). If someone > feels like writing a fix for that, it would be a nice improvement. Perhaps, > rather than having the client code know all the locations where core files > might appear, failed runs should walk the test directory tree for core files? I think this might end up having the same code to walk the directory spread out on multiple files. Instead, I think in the build script, in get_stack_trace(), we can do an equivalent of "find <inputdir> -name "*core*" , as against the current way in which it looks for core files only in the specific data directory. So get_stack_trace(bindir, datadir) would change to get_stack_trace(bindir, input_dir) where input_dir can be any directory that can contain multiple data directories. E.g. a recovery test can create multiple instances so there would be multiple data directories inside the test directory. Noah, is it possible to run a patch'ed build script once I submit a patch, so that we can quickly get the stack trace ? I mean, can we do this before getting the patch committed ? I guess, we can run the build script with a single branch specified, right ? -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: