pg.ddx.io  pgsql-general@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: rob stone <floriparob@gmail.com>
To: Justin Pryzby <pryzby@telsasoft.com>
To: PegoraroF10 <marcos@f10.com.br>
Cc: pgsql-general@postgresql.org
Subject: Re: Server goes to Recovery Mode when run a SQL
Date: Sun, 10 Feb 2019 15:15:38 +1100
Message-ID: <b89edc1e814863db892ba74332ad6ccaf4eccc9f.camel@gmail.com> (raw)
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>

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







view thread (36+ messages)  latest in thread

Message-ID: <b89edc1e814863db892ba74332ad6ccaf4eccc9f.camel@gmail.com>
Permalink:  ../b89edc1e814863db892ba74332ad6ccaf4eccc9f.camel@gmail.com/
Also on:    postgresql.org/message-id/b89edc1e814863db892ba74332ad6ccaf4eccc9f.camel@gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-general@postgresql.org
  Cc: floriparob@gmail.com, pryzby@telsasoft.com, marcos@f10.com.br
  Subject: Re: Server goes to Recovery Mode when run a SQL
  In-Reply-To: <b89edc1e814863db892ba74332ad6ccaf4eccc9f.camel@gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox