Re: canceling statement due to user request

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Todd Spangler" <ToddSpangler(at)comsys(dot)com>, <pgsql-bugs(at)postgresql(dot)org>
Cc: "Rob Lovell" <RLovell(at)nationwidecustomhomes(dot)com>
Subject: Re: canceling statement due to user request
Date: 2010-06-02 14:12:15
Message-ID: 4C06206F0200002500031CA4@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Spangler, Todd" <ToddSpangler(at)comsys(dot)com> wrote:

> canceling statement due to user request

> I cannot seem to fix.

Your application is canceling queries, probably because they're not
completing as quickly as it wants them to; that's not a PostgreSQL
bug. You should probably gather a bit more information and post to
the pgsql-performance list, to see what you can do to improve the
query speed.

> I have read that this may have something to do with the Autovacuum
> feature.

Probably not -- at least not directly. It's possible that you
aren't vacuuming aggressively enough, and therefore suffer poor
performance from bloat, but at this point, that's just conjecture.

> It seems the errors do not happen every time.

What pattern is there? Do they come in clusters? Is it particular
queries? Is it particular search arguments for a query?

> If this is the Autovacuum feature, is there a way that I can
> disable this feature and then re-enable it when I am done with the
> creation of my report?

That would probably be counter-productive, although setting
autovacuum cost limits to pace the vacuums might possibly be useful.

> Also, when we receive these errors, it does not save any
> information to the text file like it normally would without the
> error message, so we do not get the report we need when these
> errors occur.

What text file is that? With our configuration, we *do* see
statement text for these in the PostgreSQL log files.

> Another thought would be for us to allow the Autovacuum to be
> turned on only at certain times.

That would be pretty risky, and probably counter-productive.

> I have read that these messages are by design

I'm curious what you read. Can you share a URL?

> I need an easy to use workaround that will allow the reports to
> work. These reports are very important to the company.

Please read these pages and post again to a different list with more
detail:

http://wiki.postgresql.org/wiki/Guide_to_reporting_problems

http://wiki.postgresql.org/wiki/SlowQueryQuestions

In particular, since this could be related to checkpoints, it is
important to have a good description of your hardware, especially
your disk storage system, and all settings in your postgresql.conf
file (excluding all comments).

-Kevin

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Jaime Casanova 2010-06-02 14:55:59 Re: Support on Postgres Database Corruption
Previous Message botak 2010-06-02 13:38:02 Support on Postgres Database Corruption