@pgsql

Страница 959 из 1062
 
Bogdan (SirEdvin)
29.08.2018
15:22:37
Похоже на corrupted WAL record, странно... А какая версия PostgreSQL? И глупый вопрос: primary_conninfo и путь к архиву точно правильные?
10.1, вроде да, на всякий случай проверю

 
Yaroslav
29.08.2018
15:25:43
10.1, вроде да, на всякий случай проверю
А почему не 10.5? ;) А если попробовать pg_waldump на этом файле (на master), он нормально читается (а то мало ли...)?

 
Daniel
29.08.2018
17:52:01
Привет всем, у меня вопрос. Мигрирую я проект короче с MySQL на PostgreSQL. Запрос: security=# \timing Timing is on. security=# SELECT t0.token AS token_1, t0.expires_at AS expires_at_2, t0.scope AS scope_3, t0.id AS id_4, t0.client_id AS client_id_5, t0.user_id AS user_id_6 FROM oauth_access_tokens t0 WHERE t0.token = 'NTNmODU0YTU2NTQyN2U0MmZiZDE3YmEwOWVlZmQ0Njk4NmVkZjIyZjYxZTU1NmM3M2Q3OTc5NGMwZDI2ZWZhMg' LIMIT 1; token_1 | expires_at_2 | scope_3 | id_4 | client_id_5 | user_id_6 ----------------------------------------------------------------------------------------+--------------+---------+------+-------------+----------- .................................................. Time: 61,932 ms

 
Вот такой простой запрос Time: 61,932 ms

Google
 
Daniel
29.08.2018
17:53:40
MySQL выполнил за 0.7 ms

 
Александр
29.08.2018
17:54:11
Vacuum analyze выполнял?

 
Daniel
29.08.2018
17:54:12
209 записей в таблице

 
Александр
29.08.2018
17:55:40
Все равно нужно выполнить после наката дампа, или подождать

 
Daniel
29.08.2018
17:55:50
Сделал сейчас: security=# VACUUM ANALYZE oauth_access_tokens; VACUUM Time: 88,971 ms После выполнил тот же запрос - тайминг такой же

 
Denis
29.08.2018
17:56:16
покажите explain (analyze, buffers) ...

 
Александр
29.08.2018
17:56:21
Жесткий тот же?

 
Сергей
29.08.2018
17:57:02
покажи explain

 
Denis
29.08.2018
17:58:32
хотя даже для секскана по двумстам записям много

 
Александр
29.08.2018
17:59:08
Ну тут по любому секскан

 
Сергей
29.08.2018
17:59:29
ну щас узнаем) или не узнаем

 
Александр
29.08.2018
17:59:36
Селектится много полей

 
Daniel
29.08.2018
17:59:41
EXPLAIN ANALYZE + тот запрос - https://explain.depesz.com/s/Z6NS

Google
 
Александр
29.08.2018
18:00:57
А индекса нет?

 
По токену

 
Daniel
29.08.2018
18:01:47
Неа

 
Александр
29.08.2018
18:01:54
Buffers не прописывал в explain

 
Сергей
29.08.2018
18:02:07
да тут не в индексе дела. на 200 записях пофиг на индекс

 
а че за комп?)

 
Daniel
29.08.2018
18:02:13
https://explain.depesz.com/s/pg7X - с BUFFERS

 
Сергей
29.08.2018
18:02:15
и диск

 
Daniel
29.08.2018
18:02:17
Не сразу дошло как сделать

 
Сергей
29.08.2018
18:03:09
выглядит все нормально, кто видит что-то лишнее?)

 
Denis
29.08.2018
18:03:20
а там нет никаких функций в запросе?

 
Александр
29.08.2018
18:03:56
Быстрее щас выполнился

 
Сергей
29.08.2018
18:03:59
а на каком железе исполняется запрос?

 
Александр
29.08.2018
18:04:18
Actual time

 
Denis
29.08.2018
18:04:57
интересно, почему actual time <> execution time

 
а какая версия PostgreSQL?

 
Александр
29.08.2018
18:05:31
Потому что планирование как минимум

 
Denis
29.08.2018
18:06:12
ну планирование там тоже видно, и там разного порядка значения

 
Сергей
29.08.2018
18:07:17
а поле token уникально?

 
Daniel
29.08.2018
18:07:45
1)Голый посгрес 10, PostgreSQL 10.5 (Debian 10.5-1.pgdg90+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit 2)Он в докере фак 3)Диск SSD, шо тут сказать. Если подскажите команду ubuntu, я смогу предоставить больше инфы :( 4)Intel(R) Atom(TM) CPU C3955 @ 2.10GHz, но это виртуалка на scaleway...

Google
 
Александр
29.08.2018
18:08:03
В mysql с sql_no_cache выполнял?

 
Вот зря в докер

 
Сергей
29.08.2018
18:08:28
тут тормозит не посгрес кароче

 
смонтируй на реальный диск его

 
Daniel
29.08.2018
18:09:05
а поле token уникально?
А, да CREATE UNIQUE INDEX "UNIQ_CA42527C5F37A13B" ON oauth_access_tokens (token) CREATE INDEX "IDX_CA42527C19EB6921" ON oauth_access_tokens (client_id) CREATE INDEX "IDX_CA42527CA76ED395" ON oauth_access_tokens (user_id)

 
Denis
29.08.2018
18:09:38
да там же buffers: hit, все из памяти читается

 
Daniel
29.08.2018
18:09:51
Т.е. 100% не диск?

 
Denis
29.08.2018
18:09:58
угу

 
Александр
29.08.2018
18:10:22
Файловый сокет докера

 
Denis
29.08.2018
18:11:21
а там у вас приватные данные? может, дадите дамп?

 
Александр
29.08.2018
18:11:49
а там у вас приватные данные? может, дадите дамп?
Generate_sequence)

 
Daniel
29.08.2018
18:13:18
К сожалению не могу дамп(( Ток вот как таблу создать, помимо индексов: CREATE TABLE oauth_access_tokens (id SERIAL NOT NULL, client_id INT NOT NULL, user_id INT DEFAULT NULL, token VARCHAR(255) NOT NULL, expires_at INT DEFAULT NULL, scope VARCHAR(255) DEFAULT NULL, PRIMARY KEY(id))

 
Denis
29.08.2018
18:16:13
?‍♂️

 
гипотеза, что что-то со средой

 
Yuriy
29.08.2018
18:16:47
o/ Мужики и Дамы, как выбрать все таблички с триггером по его имени ?

 
elfiki
29.08.2018
18:16:56
а только на этом запросе все мдленно, а остальные быстрые?

 
Daniel
29.08.2018
18:17:57
Остальные тоже такое себе Вот на голом железе посгрес, только 9: PostgreSQL 9.5.14 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609, 64-bit Там не лучше картина - https://explain.depesz.com/s/Zc2V

 
Александр
29.08.2018
18:19:10
Блин, мне интересно стало, дома проверю)

 
Yuriy
29.08.2018
18:19:16
o/ Мужики и Дамы, как выбрать все таблички с триггером по его имени ?
Наверное так ? SELECT tgoldtable, tgnewtable FROM pg_trigger WHERE tgname = 'trigger_name';

 
Denis
29.08.2018
18:20:23
Остальные тоже такое себе Вот на голом железе посгрес, только 9: PostgreSQL 9.5.14 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609, 64-bit Там не лучше картина - https://explain.depesz.com/s/Zc2V
забавно. а еще раз стрельните, чтобы из кэша читал.

Google
 
Denis
29.08.2018
18:20:34
сколько будет?

 
Daniel
29.08.2018
18:20:43
https://explain.depesz.com/s/sYwB

 
Denis
29.08.2018
18:21:57
а, бля

 
Daniel
29.08.2018
18:22:16
Ммм?

 
Denis
29.08.2018
18:22:22
там у вас 0.6мс

 
это быстро :)

 
и на том виртуальном хостинге все тоже быстро

 
Daniel
29.08.2018
18:24:16
Time: 58,329 ms Если тайминг врубить и сделать тот же запрос((

 
Denis
29.08.2018
18:24:56
пинг

 
точнее, rtt

 
до сервера

 
и обратно

 
попробуйте зайти туда по ssh и локально пострелять

 
Daniel
29.08.2018
18:28:28
Чот не шарю я в этих сетевых вопросах: rtt min/avg/max/mdev = 58.261/58.382/59.366/0.243 ms Это много?

 
Это с клиента до сервера посгре

 
Denis
29.08.2018
18:29:00
ну это примерно столько, сколько оверхеда во времени запроса вы видите выше

 
S
29.08.2018
18:44:57
например, как-то так: 2018-08-29 14:35:24.445 UTC [24] LOG: restored log file "000000010000000100000016" from archive 2018-08-29 14:35:25.197 UTC [24] LOG: record with incorrect prev-link 7000000/5 at 1/16000098 2018-08-29 14:35:25.197 UTC [24] LOG: record with incorrect prev-link 7000000/5 at 1/16000098 2018-08-29 14:35:29.211 UTC [24] LOG: restored log file "000000010000000100000016" from archive 2018-08-29 14:35:30.060 UTC [24] LOG: record with incorrect prev-link 7000000/5 at 1/16000098 2018-08-29 14:35:30.060 UTC [24] LOG: record with incorrect prev-link 7000000/5 at 1/16000098 2018-08-29 14:35:34.202 UTC [24] LOG: restored log file "000000010000000100000016" from archive 2018-08-29 14:35:35.380 UTC [24] LOG: record with incorrect prev-link 7000000/5 at 1/16000098 2018-08-29 14:35:35.381 UTC [24] LOG: record with incorrect prev-link 7000000/5 at 1/1600009
2018-08-29 14:28:17.298 UTC [131] FATAL: could not receive data from WAL stream: ERROR: requested starting point 1/16000000 is ahead of the WAL flush position of this server 1/15000060 у вас standby в будущем относительно мастера, как так? вы либо не к тому серверу коннектитесь, либо возможно по ошибке standby без recovery.conf запустили, остановили и пытаетесь снова его уже с recovery.conf запустить.

 
Bogdan (SirEdvin)
29.08.2018
18:45:32
2018-08-29 14:28:17.298 UTC [131] FATAL: could not receive data from WAL stream: ERROR: requested starting point 1/16000000 is ahead of the WAL flush position of this server 1/15000060 у вас standby в будущем относительно мастера, как так? вы либо не к тому серверу коннектитесь, либо возможно по ошибке standby без recovery.conf запустили, остановили и пытаетесь снова его уже с recovery.conf запустить.
ооооо, спасибо. Вот это моя ошибка :)

 
Yaroslav
29.08.2018
19:21:32
ооооо, спасибо. Вот это моя ошибка :)
Писал же Вам проверить conninfo/архив. ;)

 
Terminator
30.08.2018
01:09:41
td будет жить. Поприветствуем!

Google
 
Terminator
30.08.2018
06:31:32
@dodonov56 будет жить. Поприветствуем!

 
valera
30.08.2018
06:34:51
Добрый день! Подскажите по следующему вопросу Вчера начал пользоваться psql, и столкнулся, что, например, если некорректно ввести, к примеру, в запросе инсерт инто(name) и вот к примеру 'qwe (без закрывающей) то консоль перестает на что дибо реагировать в т ч и на ; . Как решить проблему без перезапуска?

 
Alexander
30.08.2018
06:36:15
ctrl+c

 
она просто ждёт продолжения команды на следующей строке

 
Eagle Owl
30.08.2018
06:37:24
Привет. Посоветуйте, пожалуйста, книжку по продвинутой работе с SQL (Любой диалект). Где подробно рассказано про уровни изоляции транзакций, кластерные индексы, хранимые процедуры, блокировки и иже с ними. Что-нибудь популярное в духе O'Reilly.

 
Bogdan (SirEdvin)
30.08.2018
06:38:48
Писал же Вам проверить conninfo/архив. ;)
Ну, именно с проверкой все было в порядке. Я просто разворачиваю скриптами и там как раз была такая странная логика, что сначала запускается postgres (что бы создать папку кластера), а потом уже конфиг recovery ставится.

 
А так все решилось

Страница 959 из 1062