Message-ID: <b89edc1e814863db892ba74332ad6ccaf4eccc9f.camel@gmail.com>
Subject: Re: Server goes to Recovery Mode when run a SQL
From: rob stone <floriparob@gmail.com>
To: Justin Pryzby <pryzby@telsasoft.com>, PegoraroF10 <marcos@f10.com.br>
Cc: pgsql-general@postgresql.org
Date: Sun, 10 Feb 2019 15:15:38 +1100
In-Reply-To: <20190209214651.GP31721@telsasoft.com>
References: <1549209182255-0.post@n3.nabble.com>
	 <1549209942200-0.post@n3.nabble.com> <1549660293178-0.post@n3.nabble.com>
	 <20190209214651.GP31721@telsasoft.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.4-1 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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