Thread: canceling statement due to user request

Dear PostgreSQL,

I have been working with a web application that allows saving of reports
to a text file using PostgreSQL.  The application has worked fine for
about 6 months and now we are getting the following 2 error messages:

=20

canceling statement due to statement timeout

canceling statement due to user request

=20

In development, I seem to have been able to keep the timeout messagebox
from showing up by adding a timeout to the connectionstring, but the
other error I cannot seem to fix.

=20

I have read that this may have something to do with the Autovacuum
feature.  We are using PostgreSQL version 8.3.  I'm testing with 8.4 on
another server and still am getting the messages above.  It seems the
errors do not happen every time.  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?  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.  Another thought would be for us to allow
the Autovacuum to be turned on only at certain times.  That would be
fine for our situation.

=20

I have read that these messages are by design and I am fine with that,
but I need an easy to use workaround that will allow the reports to
work.  These reports are very important to the company.=20

=20

We are using Windows Servers and Windows XP, C#.Net 2008  - ASP.Net, and
PostgreSQL 8.3.

=20

Thank you for your time,

=20

Todd Spangler

COMSYS - A Manpower Company
804-521-5288

=20

"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