If I do a "set max_parallel_workers_per_gather=0;" before I run the query
in that session, it runs just fine.
If I set it to 2, the query dies with the dsa_allocate error.
I'll use that as a work around until 10.2 comes out. Thanks! I have
something that will help.
On Mon, Jan 29, 2018 at 3:52
On Tue, Jan 30, 2018 at 5:37 AM, Tom Lane wrote:
> Rick Otten writes:
>> I'm wondering if there is anything I can tune in my PG 10.1 database to
>> avoid these errors:
>
>> $ psql -f failing_query.sql
>> psql:failing_query.sql:46: ERROR: dsa_allocate could not find 7 free pages
>> CONTEXT: par
Rick Otten writes:
> I'm wondering if there is anything I can tune in my PG 10.1 database to
> avoid these errors:
> $ psql -f failing_query.sql
> psql:failing_query.sql:46: ERROR: dsa_allocate could not find 7 free pages
> CONTEXT: parallel worker
Hmm. There's only one place in the source c
I'm wondering if there is anything I can tune in my PG 10.1 database to
avoid these errors:
$ psql -f failing_query.sql
psql:failing_query.sql:46: ERROR: dsa_allocate could not find 7 free pages
CONTEXT: parallel worker
I tried throttling back the number of parallel workers to just 2, that
did
Hi,
I'm currently migrating an oracle schema to postgresql. In the oracle`s
schema there is a table partition that has partitions by range(date - for
every day) and each partition has a sub partition by list(some values..).
Moreover, the data is loaded from a csv in a bulk. One important thing is
t
