Re: BUG #3790: pg_restore error canceling statement due touser request

The following bug has been logged online:

Bug reference: 3790
Logged by: Mike C.
Email address: smith(dot)not(dot)western(at)gmail(dot)com
PostgreSQL version: 8.3beta3
Operating system: Linux 2.6.16.21-0.8-xen #1 SMP Mon Jul 3 18:25:39 UTC
2006 i686 i686 i386 GNU/Linux
Description: pg_restore error canceling statement due to user request
Details:

I don't know if this is either a wording change, or a more serious bug, but
when I do a pg_restore (from a 8.1.9 setup) to a fresh 8.3beta3 created
database (createdb command only), I repeatedly see:

ERROR: canceling statement due to user request
CONTEXT: automatic analyze of table "dbs.public.entity_event"
ERROR: canceling statement due to user request
CONTEXT: automatic analyze of table "dbs.public.status_event"
ERROR: canceling statement due to user request
CONTEXT: automatic analyze of table "dbs.public.entity_event"
ERROR: canceling statement due to user request
CONTEXT: automatic analyze of table "dbs.public.entity_event"

... For all tables I believe.

"Mike C." <smith(dot)not(dot)western(at)gmail(dot)com> writes:

> I don't know if this is either a wording change, or a more serious bug, but
> when I do a pg_restore (from a 8.1.9 setup) to a fresh 8.3beta3 created
> database (createdb command only), I repeatedly see:
>
> ERROR: canceling statement due to user request
> CONTEXT: automatic analyze of table "dbs.public.entity_event"

This is intentional, though perhaps the wording is confusing. What impression
does the wording give you? Does it make you think something has gone wrong?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning

On 11/30/07, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>
>
> "Mike C." <smith(dot)not(dot)western(at)gmail(dot)com> writes:
>
> > I don't know if this is either a wording change, or a more serious bug,
> but
> > when I do a pg_restore (from a 8.1.9 setup) to a fresh 8.3beta3 created
> > database (createdb command only), I repeatedly see:
> >
> > ERROR: canceling statement due to user request
> > CONTEXT: automatic analyze of table "dbs.public.entity_event"
>
> This is intentional, though perhaps the wording is confusing. What
> impression
> does the wording give you? Does it make you think something has gone
> wrong?

I find that a little confusing too, why would it say "user request" when
user didn't request anything?

--
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> Ask me about EnterpriseDB's On-Demand Production Tuning
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Usama Munir Dar http://linkedin.com/in/usamadar
Consultant Architect
Cell:+92 321 5020666
Skype: usamadar

como es el pg_dump y pg_restore que usas?

Saludos Fernando

Mike C. wrote:
> The following bug has been logged online:
>
> Bug reference: 3790
> Logged by: Mike C.
> Email address: smith(dot)not(dot)western(at)gmail(dot)com
> PostgreSQL version: 8.3beta3
> Operating system: Linux 2.6.16.21-0.8-xen #1 SMP Mon Jul 3 18:25:39 UTC
> 2006 i686 i686 i386 GNU/Linux
> Description: pg_restore error canceling statement due to user request
> Details:
>
> I don't know if this is either a wording change, or a more serious bug, but
> when I do a pg_restore (from a 8.1.9 setup) to a fresh 8.3beta3 created
> database (createdb command only), I repeatedly see:
>
> ERROR: canceling statement due to user request
> CONTEXT: automatic analyze of table "dbs.public.entity_event"
> ERROR: canceling statement due to user request
> CONTEXT: automatic analyze of table "dbs.public.status_event"
> ERROR: canceling statement due to user request
> CONTEXT: automatic analyze of table "dbs.public.entity_event"
> ERROR: canceling statement due to user request
> CONTEXT: automatic analyze of table "dbs.public.entity_event"
>
> ... For all tables I believe.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
>

>>> On Fri, Nov 30, 2007 at 4:13 AM, in message
<87y7cgavmm(dot)fsf(at)oxford(dot)xeocode(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>
wrote:
> "Mike C." <smith(dot)not(dot)western(at)gmail(dot)com> writes:
>
>> I don't know if this is either a wording change, or a more serious bug, but
>> when I do a pg_restore (from a 8.1.9 setup) to a fresh 8.3beta3 created
>> database (createdb command only), I repeatedly see:
>>
>> ERROR: canceling statement due to user request
>> CONTEXT: automatic analyze of table "dbs.public.entity_event"
>
> This is intentional, though perhaps the wording is confusing. What
> impression
> does the wording give you? Does it make you think something has gone wrong?

It does say "ERROR" and "user request" when it's not an error
and the user didn't explicitly (or directly) request a cancel.

If I hadn't read the hackers thread, it would confuse me.

-Kevin

On Fri, Nov 30, 2007 at 10:13:53AM +0000, Gregory Stark wrote:
>
> "Mike C." <smith(dot)not(dot)western(at)gmail(dot)com> writes:
>
> > I don't know if this is either a wording change, or a more serious bug, but
> > when I do a pg_restore (from a 8.1.9 setup) to a fresh 8.3beta3 created
> > database (createdb command only), I repeatedly see:
> >
> > ERROR: canceling statement due to user request
> > CONTEXT: automatic analyze of table "dbs.public.entity_event"
>
> This is intentional, though perhaps the wording is confusing. What impression
> does the wording give you? Does it make you think something has gone wrong?

The fact that it says ERROR kind of hints that something has gone wrong,
no? (so yes, I agree the wording isn't very good)

//Magnus

Magnus Hagander wrote:
> On Fri, Nov 30, 2007 at 10:13:53AM +0000, Gregory Stark wrote:
> >
> > "Mike C." <smith(dot)not(dot)western(at)gmail(dot)com> writes:
> >
> > > I don't know if this is either a wording change, or a more serious bug, but
> > > when I do a pg_restore (from a 8.1.9 setup) to a fresh 8.3beta3 created
> > > database (createdb command only), I repeatedly see:
> > >
> > > ERROR: canceling statement due to user request
> > > CONTEXT: automatic analyze of table "dbs.public.entity_event"
> >
> > This is intentional, though perhaps the wording is confusing. What impression
> > does the wording give you? Does it make you think something has gone wrong?
>
> The fact that it says ERROR kind of hints that something has gone wrong,
> no? (so yes, I agree the wording isn't very good)

What is causing this? Statement_timeout? I see different wording for
that behavior. Is the postmaster getting a signal from somewhere on the
system?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian escribió:
> Magnus Hagander wrote:
> > On Fri, Nov 30, 2007 at 10:13:53AM +0000, Gregory Stark wrote:
> > >
> > > "Mike C." <smith(dot)not(dot)western(at)gmail(dot)com> writes:
> > >
> > > > I don't know if this is either a wording change, or a more serious bug, but
> > > > when I do a pg_restore (from a 8.1.9 setup) to a fresh 8.3beta3 created
> > > > database (createdb command only), I repeatedly see:
> > > >
> > > > ERROR: canceling statement due to user request
> > > > CONTEXT: automatic analyze of table "dbs.public.entity_event"
> > >
> > > This is intentional, though perhaps the wording is confusing. What impression
> > > does the wording give you? Does it make you think something has gone wrong?
> >
> > The fact that it says ERROR kind of hints that something has gone wrong,
> > no? (so yes, I agree the wording isn't very good)
>
> What is causing this? Statement_timeout? I see different wording for
> that behavior. Is the postmaster getting a signal from somewhere on the
> system?

It's the new autovacuum cancel stuff.

--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"That sort of implies that there are Emacs keystrokes which aren't obscure.
I've been using it daily for 2 years now and have yet to discover any key
sequence which makes any sense." (Paul Thomas)

"Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org> writes:

> Bruce Momjian escribió:
>> Magnus Hagander wrote:
>> > On Fri, Nov 30, 2007 at 10:13:53AM +0000, Gregory Stark wrote:
>> > >
>> > > "Mike C." <smith(dot)not(dot)western(at)gmail(dot)com> writes:
>> > >
>> > > > ERROR: canceling statement due to user request
>> > > > CONTEXT: automatic analyze of table "dbs.public.entity_event"
>> > >
>> > > This is intentional, though perhaps the wording is confusing. What impression
>> > > does the wording give you? Does it make you think something has gone wrong?
>> >
>> > The fact that it says ERROR kind of hints that something has gone wrong,
>> > no? (so yes, I agree the wording isn't very good)
>>
>> What is causing this? Statement_timeout? I see different wording for
>> that behavior. Is the postmaster getting a signal from somewhere on the
>> system?
>
> It's the new autovacuum cancel stuff.

I guess we should capture this error with a PG_TRY and silently abort instead.
Just a NOTICE or INFO should be sufficient. Other errors should of course be
rethrown.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> I guess we should capture this error with a PG_TRY and silently abort instead.
> Just a NOTICE or INFO should be sufficient. Other errors should of course be
> rethrown.

This falls in the category of "destabilizing the code for purely
cosmetic reasons", and would be a foolish change to make at RC1 time.

We could change the text of the ERROR message reasonably easily,
but changing the basic transaction abort method is right out.

regards, tom lane

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> This falls in the category of "destabilizing the code for purely
> cosmetic reasons", and would be a foolish change to make at RC1 time.

I suppose. Expect to have more bug reports like this one then though.

> We could change the text of the ERROR message reasonably easily,
> but changing the basic transaction abort method is right out.

I fear having a message saying "ERROR This is not an error" is going to get us
laughed at.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!

Gregory Stark escribió:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> > This falls in the category of "destabilizing the code for purely
> > cosmetic reasons", and would be a foolish change to make at RC1 time.
>
> I suppose. Expect to have more bug reports like this one then though.
>
> > We could change the text of the ERROR message reasonably easily,
> > but changing the basic transaction abort method is right out.
>
> I fear having a message saying "ERROR This is not an error" is going to get us
> laughed at.

I don't advocate changing that ERROR to anything else. The message
wording, as Tom says, can easily be changed -- I think this patch should
be enough. Feel free to propose better wording.

--
Alvaro Herrera http://www.PlanetPostgreSQL.org/
Voy a acabar con todos los humanos / con los humanos yo acabaré
voy a acabar con todos / con todos los humanos acabaré (Bender)

Alvaro Herrera wrote:
> Bruce Momjian escribi??:
> > Magnus Hagander wrote:
> > > On Fri, Nov 30, 2007 at 10:13:53AM +0000, Gregory Stark wrote:
> > > >
> > > > "Mike C." <smith(dot)not(dot)western(at)gmail(dot)com> writes:
> > > >
> > > > > I don't know if this is either a wording change, or a more serious bug, but
> > > > > when I do a pg_restore (from a 8.1.9 setup) to a fresh 8.3beta3 created
> > > > > database (createdb command only), I repeatedly see:
> > > > >
> > > > > ERROR: canceling statement due to user request
> > > > > CONTEXT: automatic analyze of table "dbs.public.entity_event"
> > > >
> > > > This is intentional, though perhaps the wording is confusing. What impression
> > > > does the wording give you? Does it make you think something has gone wrong?
> > >
> > > The fact that it says ERROR kind of hints that something has gone wrong,
> > > no? (so yes, I agree the wording isn't very good)
> >
> > What is causing this? Statement_timeout? I see different wording for
> > that behavior. Is the postmaster getting a signal from somewhere on the
> > system?
>
> It's the new autovacuum cancel stuff.

Ah, OK. Right now we have these two cancel messages:

if (cancel_from_timeout)
ereport(ERROR,
(errcode(ERRCODE_QUERY_CANCELED),
errmsg("canceling statement due to statement timeout")));
else
ereport(ERROR,
(errcode(ERRCODE_QUERY_CANCELED),
errmsg("canceling statement due to user request")));

While the first one is fine, the second one is used for Control-C and
the new autovacuum code to exit an activity when it is blocking someone
from getting a table lock. Perhaps we just need to change the wording
to "canceling statement" and not specify the cause.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian escribió:
> Alvaro Herrera wrote:

> Ah, OK. Right now we have these two cancel messages:
>
> if (cancel_from_timeout)
> ereport(ERROR,
> (errcode(ERRCODE_QUERY_CANCELED),
> errmsg("canceling statement due to statement timeout")));
> else
> ereport(ERROR,
> (errcode(ERRCODE_QUERY_CANCELED),
> errmsg("canceling statement due to user request")));
>
> While the first one is fine, the second one is used for Control-C and
> the new autovacuum code to exit an activity when it is blocking someone
> from getting a table lock. Perhaps we just need to change the wording
> to "canceling statement" and not specify the cause.

We can distinguish the cases -- there's no need to mix them in a single
message. See the patch I attached somewhere else in this thread.

--
Alvaro Herrera http://www.advogato.org/person/alvherre
"No hay hombre que no aspire a la plenitud, es decir,
la suma de experiencias de que un hombre es capaz"

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> I don't advocate changing that ERROR to anything else. The message
> wording, as Tom says, can easily be changed -- I think this patch should
> be enough. Feel free to propose better wording.

Minor gripe: all three variants of the message should follow the same
sentence construction. So perhaps "canceling autovacuum task".

Other than the wording issue, this seems about the right fix to me.

regards, tom lane

Tom Lane escribió:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > I don't advocate changing that ERROR to anything else. The message
> > wording, as Tom says, can easily be changed -- I think this patch should
> > be enough. Feel free to propose better wording.
>
> Minor gripe: all three variants of the message should follow the same
> sentence construction. So perhaps "canceling autovacuum task".

Ok, committed using that wording and spelling.

--
Alvaro Herrera http://www.PlanetPostgreSQL.org/
"Some men are heterosexual, and some are bisexual, and some
men don't think about sex at all... they become lawyers" (Woody Allen)

On Thu, 2007-12-06 at 11:33 -0300, Alvaro Herrera wrote:
> Tom Lane escribió:
> > Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > > I don't advocate changing that ERROR to anything else. The message
> > > wording, as Tom says, can easily be changed -- I think this patch should
> > > be enough. Feel free to propose better wording.
> >
> > Minor gripe: all three variants of the message should follow the same
> > sentence construction. So perhaps "canceling autovacuum task".
>
> Ok, committed using that wording and spelling.

Sorry to come in on late on this: That wording is better, but it still
doesn't explain why it has occurred or what the user should do about it.
I think we will get other complaints saying "why has my autovacuum been
canceled?" and "what should I do about this?".

Perhaps it should be
"canceling autovacuum task; will reschedule when user tasks complete"
or
"autovacuum canceled temporarily to allow user task to proceed"

or something that explains that what has happened is a good thing and
the task that has been canceled will be automatically re-tried.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

Simon Riggs escribió:

> Sorry to come in on late on this: That wording is better, but it still
> doesn't explain why it has occurred or what the user should do about it.
> I think we will get other complaints saying "why has my autovacuum been
> canceled?" and "what should I do about this?".
>
> Perhaps it should be
> "canceling autovacuum task; will reschedule when user tasks complete"
> or
> "autovacuum canceled temporarily to allow user task to proceed"
>
> or something that explains that what has happened is a good thing and
> the task that has been canceled will be automatically re-tried.

Perhaps the added phrase could be put in a errdetail() or something like
that. The problem is detecting that this is really the case. How would
it know that it wasn't user-inflicted?

--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"Las navajas y los monos deben estar siempre distantes" (Germán Poo)

On Thu, 2007-12-06 at 12:03 -0300, Alvaro Herrera wrote:
> Simon Riggs escribió:
>
> > Sorry to come in on late on this: That wording is better, but it still
> > doesn't explain why it has occurred or what the user should do about it.
> > I think we will get other complaints saying "why has my autovacuum been
> > canceled?" and "what should I do about this?".
> >
> > Perhaps it should be
> > "canceling autovacuum task; will reschedule when user tasks complete"
> > or
> > "autovacuum canceled temporarily to allow user task to proceed"
> >
> > or something that explains that what has happened is a good thing and
> > the task that has been canceled will be automatically re-tried.
>
> Perhaps the added phrase could be put in a errdetail() or something like
> that. The problem is detecting that this is really the case. How would
> it know that it wasn't user-inflicted?

True. We can say "task will be automatically re-scheduled", so that
people understand the message and don't start asking us.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> True. We can say "task will be automatically re-scheduled", so that
> people understand the message and don't start asking us.

How about "temporarily canceling autovacuum task"? This is accurate
regardless of the origin of the SIGINT.

regards, tom lane

Tom Lane escribió:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > True. We can say "task will be automatically re-scheduled", so that
> > people understand the message and don't start asking us.
>
> How about "temporarily canceling autovacuum task"? This is accurate
> regardless of the origin of the SIGINT.

"postponing autovacuum task"?

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"No es bueno caminar con un hombre muerto"

On Thu, 2007-12-06 at 12:24 -0300, Alvaro Herrera wrote:
> Tom Lane escribió:
> > Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > > True. We can say "task will be automatically re-scheduled", so that
> > > people understand the message and don't start asking us.
> >
> > How about "temporarily canceling autovacuum task"? This is accurate
> > regardless of the origin of the SIGINT.
>
> "postponing autovacuum task"?

I prefer Tom's version. It fits better with the ERROR word in front of
this text.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com