BUG #3790: pg_restore error canceling statement due to user request

"Mike C." <smith.not.western@gmail.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@enterprisedb.com> wrote:

"Mike C." <smith.not.western@gmail.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@postgresql.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:

On Fri, Nov 30, 2007 at 4:13 AM, in message

<87y7cgavmm.fsf@oxford.xeocode.com>, Gregory Stark <stark@enterprisedb.com>
wrote:

"Mike C." <smith.not.western@gmail.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.not.western@gmail.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.not.western@gmail.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@momjian.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.not.western@gmail.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@alvh.no-ip.org> writes:

Bruce Momjian escribió:

Magnus Hagander wrote:

On Fri, Nov 30, 2007 at 10:13:53AM +0000, Gregory Stark wrote:

"Mike C." <smith.not.western@gmail.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@enterprisedb.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@sss.pgh.pa.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@sss.pgh.pa.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.not.western@gmail.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@momjian.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@alvh.no-ip.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@alvh.no-ip.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@alvh.no-ip.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@2ndquadrant.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