Re: BUG #3790: pg_restore error canceling statement due touser request
От | Gregory Stark |
---|---|
Тема | Re: BUG #3790: pg_restore error canceling statement due touser request |
Дата | |
Msg-id | 878x4asxmt.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: BUG #3790: pg_restore error canceling statement due to user request (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: BUG #3790: pg_restore error canceling statement due touser request
|
Список | pgsql-bugs |
"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
В списке pgsql-bugs по дате отправления: