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 по дате отправления: