Re: postgres 9.6: insert into select finishes only in pgadmin not psql

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: postgres 9.6: insert into select finishes only in pgadmin not psql
Дата
Msg-id 26981.1569247037@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: postgres 9.6: insert into select finishes only in pgadmin not psql  (Corey Taylor <corey.taylor.fl@gmail.com>)
Ответы Re: postgres 9.6: insert into select finishes only in pgadmin not psql
Список pgsql-general
Corey Taylor <corey.taylor.fl@gmail.com> writes:
> I found after testing other situations, that the psql command would always
> finish as expected after canceling the first query that ran too long.  I
> was able to reproduce this scenario with psql and pgadmin4 with various
> combinations.

Well, that's just weird.

It's well known that the second run of a query can be much faster due
to having fully-populated caches to draw on, but you seem to have a
case that may go beyond that.  Maybe check for waiting on a lock?
It'd be useful to look in pg_stat_activity and/or top(1) while the
initial query is running, to see if it seems to be eating CPU or
is blocked on some condition.  (I forget how thorough the
wait_event coverage is in 9.6, but it does at least have those
columns.)

Can you create a self-contained test case that acts like this?

            regards, tom lane



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

Предыдущее
От: Luca Ferrari
Дата:
Сообщение: Re: unable to drop index because it does not exists
Следующее
От: Pankaj Jangid
Дата:
Сообщение: Re: How to represent a bi-directional list in db?