Re: logical decoding : exceeded maxAllocatedDescs for .spill files - Mailing list pgsql-hackers

From Amit Khandekar
Subject Re: logical decoding : exceeded maxAllocatedDescs for .spill files
Date
Msg-id CAJ3gD9diTB8rqyUWo=jZrSQxvW7o-gGaO6uoF5racneH3+FYOg@mail.gmail.com
Whole thread Raw
In response to Re: logical decoding : exceeded maxAllocatedDescs for .spill files  (Noah Misch <noah@leadboat.com>)
Responses Re: logical decoding : exceeded maxAllocatedDescs for .spill files  (Noah Misch <noah@leadboat.com>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Allow 'sslkey' and 'sslcert' in postgres_fdw user mappings
Next
From: Heikki Linnakangas
Date:
Subject: Re: Improve checking for pg_index.xmin