Re: Killing a data modifying transaction

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Killing a data modifying transaction
Дата
Msg-id 18381.1245684121@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Killing a data modifying transaction  (William Temperley <willtemperley@gmail.com>)
Ответы Re: Killing a data modifying transaction  (William Temperley <willtemperley@gmail.com>)
Список pgsql-general
William Temperley <willtemperley@gmail.com> writes:
> I'm wondering if I happened as I'd started the same query twice.
> The first had work_mem = 1MB so I tried to kill it and started another
> with work_mem = 1000MB, but both were attempting to insert the same id
> into a PK:
> "insert into world (geom, id) select st_union(geom), 1 from adminunit
> where admin_level = '0'".
> Just now when I killed the first process, the other terminated.

Well, that last is expected --- as soon as you kill -9 one backend, the
postmaster is going to force-quit all the others and perform a database
restart.  So we don't really know anything more than before.

Given that they'd both be trying to insert the same PK values, it'd be
unsurprising for one of the processes to be blocked waiting to see if
the other one commits.  But didn't you say they were both eating CPU?

I'm personally inclined to think some PostGIS oddity here (which means
you might get more help asking about it on the postgis lists).  But
that's mere speculation.  A stack trace showing where it was looping
would've provided something more to go on ...

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: "Todd A. Cook"
Дата:
Сообщение: Re: FYI: Load times for a largish DB in 8.2 vs. 8.3 vs. 8.4
Следующее
От: Johan Nel
Дата:
Сообщение: Re: Build in spatial support vs. PostGIS