PostgreSQL 9.3 длинные запросы

select vesseltrav0_.id as id1_0_, vesseltrav0_.created as created2_0_, vesseltrav0_.lastUpdated as lastUpda3_0_, vesseltrav0_.geoFenceId as geoFence4_0_, 
     vesseltrav0_.geoFenceName as geoFence5_0_, vesseltrav0_.mmsi as mmsi6_0_, vesseltrav0_.position as position7_0_, vesseltrav0_.timestamp as timestam8_0_, 
     vesseltrav0_.vesselEnteredTime as vesselEn9_0_, vesseltrav0_.vesselExitTime as vesselE10_0_, vesseltrav0_.vesselId as vesselI11_0_ 
from VESSEL_ENTERED_GEOFENCE vesseltrav0_ where vesseltrav0_.geoFenceId=$1 and vesseltrav0_.vesselId=$2

У меня есть регистрация протоколов демона в базу данных и их периодическое обновление, но кажется, что один или два часа этот довольно невинно выглядящий SQL просто откажется закончить.PostgreSQL 9.3 длинные запросы

CREATE TABLE public.vessel_entered_geofence 
(
    id bigint NOT NULL, 
    geofenceid character varying(36), 
    geofencename character varying(128), 
    mmsi character varying(32), 
    vesselenteredtime timestamp without time zone, 
    vesselexittime timestamp without time zone, 
    vesselid character varying(36), 
    created timestamp without time zone, 
    lastupdated timestamp without time zone, 
    "position" geometry(Point,4326), 
    "timestamp" timestamp without time zone, 
    CONSTRAINT vessel_entered_geofence_pkey PRIMARY KEY (id) 
) 
WITH (
    OIDS=FALSE 
); 

CREATE INDEX vessel_entered_geofence_idx 
    ON public.vessel_entered_geofence 
    USING btree 
    (mmsi COLLATE pg_catalog."default"); 

CREATE INDEX vessel_entered_geofence_gid_idx 
ON public.vessel_entered_geofence 
USING btree 
(geofenceid COLLATE pg_catalog."default"); 

CREATE INDEX vessel_entered_geofence_vid_idx 
ON public.vessel_entered_geofence 
USING btree 
(vesselid COLLATE pg_catalog."default");

Когда я запускаю план объяснить на SQL она использует индекс и вручную запущена SQL возвращает ответ очень быстро. Все соединения имеют состояние бездействия (редактирование: все они «бездействуют в транзакции»), и они ничего не ждут (согласно pg_stats_activity).

select * from pg_stat_activity order by backend_start

enter image description here http://i.stack.imgur.com/0pp8X.png

select a.*, b.relname from pg_locks a left outer join pg_class b on a.relation = b.oid

enter image description here https://puu.sh/gGE9n/96da69d341.png

Я не совсем уверен, где искать дальше, чтобы определить, что проблема в том, что они, как представляется, в режиме ожидания, не дожидаясь что угодно, и на столе нет замков, которые должны приводить к зависанию (если я не ошибаюсь). Любая помощь будет оценена по достоинству.

источник

2015-03-19 user1671538

демон работает, если вы указали сверху? .. –

Это текст запроса, возвращаемый pg_stat_activity.query. Но да, это вызвано из Java Daemon изначально – user1671538

oh jaaaaavaaaa ... Теперь я вижу. У меня было такое же, что и java, не завершая соединение после завершения. Мы этого не решили - только что создали работу, чтобы закончить java, если она завершила выполнение и не вышла :) –

Думаю, я решил это наконец. В коде Java отсутствовал запуск/фиксация.

entityManager.getTransaction().begin(); 
//perform query 
entityManager.getTransaction().commit();

Даже если запрос содержит только оператор выбора, она будет висеть, если вы не инкапсулировать его в сделке.

источник

2015-03-20 15:50:18 user1671538

PostgreSQL 9.3 длинные запросы

ответ

Смежные вопросы