On 22 June 2018 at 03:05, Sara Pranke <sara.pranke@gmail.com> wrote:
> I will be construct a local lab trying to reproduce this error, because
> today occur only in client machine.
> At the moment my only default is the memory consumed by the Sort plan,
> because when I excluded the clauses I saw in EXPLAIN ANALYZE consuming
> memory, the query worked.
>
> Ha, I have one more guest, if PostgreSQL can't access disk memory after
> consume or estimate more than available in work_mem, maybe this cause the
> error. I don't know, just a guest.
This error came entirely from the planner, so what may have happened
during execution would have no effect. The query just happened to not
get that far.
You should be able to recreate using the same schema+query that
failed. The actual data might not be too important, although that
likely has driven the shape of the plan. You may be able to coax the
planner into generating the same plan with empty tables by disabling
various enable_* GUCs. For example if the failing plan has a Merge
Join, then you could SET enable_hashjoin = 0; SET enable_nestloop = 0;
Although, if the plan is very complex then you may not have luck
since it may be caused by a combination of different join types, which
might be difficult to control without the data.
If you can recreate without data, then it would be great to see the
entire schema plus failing query. If further simplification of the
query is possible, e.g removing joins, columns or indexes that don't
need to be there, then that may be helpful, but probably not
necessary.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services