Re: canceling statement due to user request - Mailing list pgsql-bugs

From Kevin Grittner
Subject Re: canceling statement due to user request
Date
Msg-id 4C06206F0200002500031CA4@gw.wicourts.gov
Whole thread Raw
In response to canceling statement due to user request  ("Spangler, Todd" <ToddSpangler@comsys.com>)
List pgsql-bugs
"Spangler, Todd" <ToddSpangler@comsys.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

pgsql-bugs by date:

Previous
From: botak
Date:
Subject: Support on Postgres Database Corruption
Next
From: Jaime Casanova
Date:
Subject: Re: Support on Postgres Database Corruption