Hi,
On Sat, 2019-02-09 at 15:46 -0600, Justin Pryzby wrote:
> Hi,
>
>
>
> "segfault" seems to mean you hit a bug, which we'll want more
> information to
> diagnose. Could you install debugging symbols ? Ubuntu calls their
> package
> postgresql-10-dbg or similar. And start server with coredumps
> enabled, using
> pg_ctl -c -D /var/lib/postgresql/10/main (or similar). Then trigger
> the query
> and hope to find a core dump in the data directory. Or possibly
> it'll be
> processed into /var/crash by apport daemon, depending if that's
> running and
> enabled (check /proc/sys/kernel/core_pattern).
>
I believe there is a bug. I've examined the query Marcos sent with his
first post and I think the parser should have listed some errors and
not tried to run the query.
I'm probably wrong but consider the following.
Around line 33 of the query:-
tsrange(col_aula.data, (col_aula.data + (col_aula.tempo|| '
minute')::interval)) dia, 0 prevista,
(extract(EPOCH FROM col_aula.tempo) / 60) minutosassistidos
Assuming column col_aula.tempo is of type INTEGER, is NOT NULL and
let's say contains a value of 60, then it parses as
tsrange(col_aula.data, (col_aula.data + (60' minute')::interval))
which would pull a syntax error.
You cannot extract EPOCH from a column that is of type INTEGER. Another
syntax error.
Down around line 87 onwards there are generate_series without any
parameters, and further dubious usage of EPOCH, as well as DOW.
Not having the table definitions is obviously clouding the analysis.
If there is a bug in the parser, then one of the experts will have to
opine about that.
HTH,
Robert
