Обсуждение: 'query was cancelled' - depending on search pattern

Hello Bugs,
a query that uses pattern matching like this:
   SELECT .. WHERE  ( (content || authorname) ~* ( '.*gesellschaft.* |
.*wirtschaft.*' ) )

produces an error 'Query was cancelled' - sometimes, depending on the
search words.
Seems quite strange to me, I increased some postgresql.conf parameters,
without effect, and failed in finding anything on 'query was cancelled' in
the docs or in google.

Any hints are welcome (and an update to the docs about error messages would
make sense anyway).
// Bernd vdB

Bernd von den Brincken <bvdb@asa.de> writes:
> a query that uses pattern matching like this:
>    SELECT .. WHERE  ( (content || authorname) ~* ( '.*gesellschaft.* |
> .*wirtschaft.*' ) )
> produces an error 'Query was cancelled' - sometimes, depending on the
> search words.

That's really, really hard to believe.  I suspect you've mis-analyzed
the situation.  You sure your client-side code doesn't send cancel
requests on occasion?  Can you create a test case that would let someone
else reproduce this behavior?

            regards, tom lane

Hello Tom,

At 04.04.2003 00:22, you wrote:
>Bernd von den Brincken <bvdb@asa.de> writes:
> > a query ... produces an error 'Query was cancelled' -
> > sometimes, depending on the search words.
>
>That's really, really hard to believe.  I suspect you've mis-analyzed
>the situation.  You sure your client-side code doesn't send cancel
>requests on occasion?  Can you create a test case that would let someone
>else reproduce this behavior?

I stripped the query down a bit - this one produces the cancel:
         SELECT id FROM cftext WHERE ( content  ~* ( '.*wirt.* | .*weil.*'
) ) ;
Whereas this one provides a correct result set:
         SELECT id FROM cftext WHERE ( content  ~* ( '.*wirt.* | .*und.*' ) ) ;

My client is psql via telnet on a Toshiba T550 laptop, my version():
   PostgreSQL 7.3.2 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4

Now I tested it on a different machine (P-3 Server) with (almost) the same
DB contents - it works fine there ! - The version() says:
   PostgreSQL 7.3 on i386-unknown-freebsd4.5, compiled by GCC 2.95.3

So may the problem be in the pattern matching code that may differ
  between freebsd versions?
Regards
// Bernd vdB

Bernd von den Brincken <bvdb@asa.de> writes:
> My client is psql via telnet on a Toshiba T550 laptop, my version():
>    PostgreSQL 7.3.2 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4
> Now I tested it on a different machine (P-3 Server) with (almost) the same
> DB contents - it works fine there ! - The version() says:
>    PostgreSQL 7.3 on i386-unknown-freebsd4.5, compiled by GCC 2.95.3

> So may the problem be in the pattern matching code that may differ
>   between freebsd versions?

It's still awfully hard to see how pattern-matching code would cause a
SIGINT signal --- which AFAICS is the only way to get to 'Query was
cancelled'.

We have seen some rather weird reports of trouble on recent freebsd
releases, though.  (Right at the moment I'm comparing your report to
Doug Silver's recent post on pgsql-novice --- he's seeing bizarre
behavior of timestamps on one freebsd machine and not on another very
similar machine.)  I have a suspicion there's something broken about
the compiler or libc, but can't prove anything yet.

Can you trace through it with a debugger and try to see what's
happening?  A stack trace from the elog() call would be good for starters.

            regards, tom lane

Tom Lane wrote:

> Bernd von den Brincken <bvdb@asa.de> writes:
>> My client is psql via telnet on a Toshiba T550 laptop, my version():
>>    PostgreSQL 7.3.2 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4
>> Now I tested it on a different machine (P-3 Server) with (almost) the
>> same DB contents - it works fine there ! - The version() says:
>>    PostgreSQL 7.3 on i386-unknown-freebsd4.5, compiled by GCC 2.95.3
>
>> So may the problem be in the pattern matching code that may differ
>>   between freebsd versions?
>
> It's still awfully hard to see how pattern-matching code would cause a
> SIGINT signal --- which AFAICS is the only way to get to 'Query was
> cancelled'.
>
> We have seen some rather weird reports of trouble on recent freebsd
> releases, though.  (Right at the moment I'm comparing your report to
> Doug Silver's recent post on pgsql-novice --- he's seeing bizarre
> behavior of timestamps on one freebsd machine and not on another very
> similar machine.)  I have a suspicion there's something broken about
> the compiler or libc, but can't prove anything yet.
>
> Can you trace through it with a debugger and try to see what's
> happening?  A stack trace from the elog() call would be good for starters.
>
> regards, tom lane
>
>
> ---------------------------(end of broadcast)---------------------------


I recall seeing some libc related problems discussed on the freebsd-java
list recently.  The problems would crop up if -O2 was set during the
compile of the jdk.  Maybe there is something similar here.