Обсуждение: BUG #3790: pg_restore error canceling statement due to user request
The following bug has been logged online: Bug reference: 3790 Logged by: Mike C. Email address: smith.not.western@gmail.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.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: > The following bug has been logged online: > > Bug reference: 3790 > Logged by: Mike C. > Email address: smith.not.western@gmail.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@postgresql.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.fsf@oxford.xeocode.com>, Gregory Stark <stark@enterprisedb.com> wrote:=20 > "Mike C." <smith.not.western@gmail.com> writes: >=20 >> 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" >=20 > This is intentional, though perhaps the wording is confusing. What=20 > impression > does the wording give you? Does it make you think something has gone wron= g? =20 It does say "ERROR" and "user request" when it's not an error and the user didn't explicitly (or directly) request a cancel. =20 If I hadn't read the hackers thread, it would confuse me. =20 -Kevin =20
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=C3=B3: >> Magnus Hagander wrote: >> > On Fri, Nov 30, 2007 at 10:13:53AM +0000, Gregory Stark wrote: >> > >=20 >> > > "Mike C." <smith.not.western@gmail.com> writes: >> > >=20 >> > > > ERROR: canceling statement due to user request >> > > > CONTEXT: automatic analyze of table "dbs.public.entity_event" >> > >=20 >> > > This is intentional, though perhaps the wording is confusing. What i= mpression >> > > does the wording give you? Does it make you think something has gone= wrong? >> >=20 >> > The fact that it says ERROR kind of hints that something has gone wron= g, >> > no? (so yes, I agree the wording isn't very good) >>=20 >> 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 inste= ad. Just a NOTICE or INFO should be sufficient. Other errors should of course be rethrown. --=20 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
Tom Lane escribió: > 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. "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@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. > > "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