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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Thomas H."
Дата:
Сообщение: Re: BUG #3766: tsearch2 index creation error
Следующее
От: "Rikardo Tinauer"
Дата:
Сообщение: BUG #3798: Add fuzzy string search in TSearch2