Size: a a a

pgsql – PostgreSQL

2021 February 09

AL

Alexey Lesovsky in pgsql – PostgreSQL
в качестве дальнейшего дебага можно взять perf record/report через него посмотреть на какие функции время уходит
источник

T

The2lb3oz4dr10½grOfH... in pgsql – PostgreSQL
Артур Асриян
ну я хз что лучше. в sql всегда есть множество разных способов решить задачу. если интересует скорость то лучше всего покажут замеры.
Ну сейчас меня скорость не удовлетворила. Попытаюсьсделать и через group by
источник

b🍉

baklawan 🍉 in pgsql – PostgreSQL
всем привет. подскажите, существует ли опция "промотать" restart_lsn слота логической репликации до confirmed_flush_lsn? почему-то постгрес отказывается чистить WAL самостоятельно и при рестарте чтения консьюмер начинает перечитывать всю разницу между этими двумя lsn. спасибо
источник

VG

Viktor Grigorev in pgsql – PostgreSQL
Alexey Lesovsky
это один конкретный процесс так штормит?
разные воркеры, которые что-то делают
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
The2lb3oz4dr10½grOfHedgehogs
Вот так добился желаемого результата, но очень смущает cross join

with my_jsonb_table as (
 select unnest(array['[[], [1, 2], [3]]'::jsonb, '[[4, 5], [6], []]'::jsonb]) as val
)
select (select array_agg(values)
       from jsonb_array_elements(my_jsonb_table.val) as elements
       cross join jsonb_array_elements(elements) as values)
from my_jsonb_table;



array_agg
-----------
{1,2,3}
{4,5,6}
(2 rows)
Раз уж v13, то почему бы не:
WITH my_jsonb_table AS (
  SELECT unnest(ARRAY['[[], [1, 2], [3]]'::jsonb,
                      '[[4, 5], [6], []]'::jsonb]) AS val
)
SELECT val, jsonb_path_query_array(val, '$[*][*]')
 FROM my_jsonb_table;
источник

T

The2lb3oz4dr10½grOfH... in pgsql – PostgreSQL
Yaroslav Schekin
Раз уж v13, то почему бы не:
WITH my_jsonb_table AS (
  SELECT unnest(ARRAY['[[], [1, 2], [3]]'::jsonb,
                      '[[4, 5], [6], []]'::jsonb]) AS val
)
SELECT val, jsonb_path_query_array(val, '$[*][*]')
 FROM my_jsonb_table;
ВОУ! Это самое лучшее решение для меня
источник

T

The2lb3oz4dr10½grOfH... in pgsql – PostgreSQL
Я что-то вообще не догадался о том, что я могу сделать [*][*]. Теперь это выглядит очевидным. Спасибо. Сейчас протещщу
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
baklawan 🍉
всем привет. подскажите, существует ли опция "промотать" restart_lsn слота логической репликации до confirmed_flush_lsn? почему-то постгрес отказывается чистить WAL самостоятельно и при рестарте чтения консьюмер начинает перечитывать всю разницу между этими двумя lsn. спасибо
Там есть функции для этого... но не лучше ли разобраться, почему он отказывается?
А то так можно промотать до "развала" репликации, мало ли...
источник

b🍉

baklawan 🍉 in pgsql – PostgreSQL
Yaroslav Schekin
Там есть функции для этого... но не лучше ли разобраться, почему он отказывается?
А то так можно промотать до "развала" репликации, мало ли...
а с чего начинать разбирательство? :)
про функцию - вы pg_replication_slot_advance имеете в виду? по документации я понял что это как раз про confirmed_flush_lsn или нет?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
baklawan 🍉
а с чего начинать разбирательство? :)
про функцию - вы pg_replication_slot_advance имеете в виду? по документации я понял что это как раз про confirmed_flush_lsn или нет?
Да, её. А разве очередной CHECKPOINT после этого не двигает restart (могу путать, да)?

А разбирательство — кто его знает. ;) Проверить все данные по этому слоту / publication / subscription, для начала, например.
источник

b🍉

baklawan 🍉 in pgsql – PostgreSQL
Yaroslav Schekin
Да, её. А разве очередной CHECKPOINT после этого не двигает restart (могу путать, да)?

А разбирательство — кто его знает. ;) Проверить все данные по этому слоту / publication / subscription, для начала, например.
проблема как раз в том, что уже имеется огромное отставание restart от confirmed flush, второе значение трогать не хочется - нужно сохранить консистентность. а вот записи до confirmed flush мне совершенно не нужны и хотелось бы заставить Postgres их почистить) при этом слот один, его читает один процесс, а кто еще может блокировать WAL от чистки?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
baklawan 🍉
проблема как раз в том, что уже имеется огромное отставание restart от confirmed flush, второе значение трогать не хочется - нужно сохранить консистентность. а вот записи до confirmed flush мне совершенно не нужны и хотелось бы заставить Postgres их почистить) при этом слот один, его читает один процесс, а кто еще может блокировать WAL от чистки?
Блокировать-то может разное (другие слоты, настройки вроде wal_keep_segments и т.п.), но раз уж:

> имеется огромное отставание restart от confirmed flush

казалось бы, это оно? Т.е. что там во всех прочих view, связанных с репликацией? А на подписчике?
Т.е. он же почему-то не двигает restart_lsn.
Кстати, какие это полные версии PostgreSQL (а то мало ли... bugs в логической репликации раньше было немало)?
источник

b🍉

baklawan 🍉 in pgsql – PostgreSQL
Yaroslav Schekin
Блокировать-то может разное (другие слоты, настройки вроде wal_keep_segments и т.п.), но раз уж:

> имеется огромное отставание restart от confirmed flush

казалось бы, это оно? Т.е. что там во всех прочих view, связанных с репликацией? А на подписчике?
Т.е. он же почему-то не двигает restart_lsn.
Кстати, какие это полные версии PostgreSQL (а то мало ли... bugs в логической репликации раньше было немало)?
подписчик перебирает записи из этого лага (работает впустую т.к. знает что его интересуют записи только начиная с confirmed flush). вопрос и заключается в том, почему постгрес не хочет апдейтить restart. других слотов нет, пробовали останавливать подписчика, запускались в это время чекпоинты - все впустую. даж базу ребутнули)

версия 11.4

а из каких еще вью можно интересную для этого кейса инфу достать? а то я только pg_replication_slots смотрю. и кто кроме подписчиков через слоты может блокировать WAL от чистки?
источник

b🍉

baklawan 🍉 in pgsql – PostgreSQL
я ведь правильно понимаю, что restart_lsn полностью управляется постгресом и подписчик не может его двигать? подписчик может только обновить confirmed_flush_lsn?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
baklawan 🍉
подписчик перебирает записи из этого лага (работает впустую т.к. знает что его интересуют записи только начиная с confirmed flush). вопрос и заключается в том, почему постгрес не хочет апдейтить restart. других слотов нет, пробовали останавливать подписчика, запускались в это время чекпоинты - все впустую. даж базу ребутнули)

версия 11.4

а из каких еще вью можно интересную для этого кейса инфу достать? а то я только pg_replication_slots смотрю. и кто кроме подписчиков через слоты может блокировать WAL от чистки?
Ну так обновитесь до 11.10, а потом уже будете дальше смотреть (нет, конечно, можно все release notes прочитать на предмет подобной ошибки, но зачем?!).

А pg_stat_replication, pg_stat_subscription смотрели?
источник

AL

Alexey Lesovsky in pgsql – PostgreSQL
Viktor Grigorev
разные воркеры, которые что-то делают
попробуйте выключить параллелизм через max_parallel_workers_per_gather (достаточно релоада), либо дальше через perf смотреть
источник

b🍉

baklawan 🍉 in pgsql – PostgreSQL
Yaroslav Schekin
Ну так обновитесь до 11.10, а потом уже будете дальше смотреть (нет, конечно, можно все release notes прочитать на предмет подобной ошибки, но зачем?!).

А pg_stat_replication, pg_stat_subscription смотрели?
спасибо за наводку, глянул. pg_stat_subscription - пусто, pg_stat_replication - оказалось что есть еще один процесс, rds репликация, но она вообще up-to-date, в то время как мой консьюмер топчется в лаге. у него flush_lsn, replay_lsn = confirmed_flush_lsn, а sent_lsn, write_lsn - в интервале лага
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
baklawan 🍉
спасибо за наводку, глянул. pg_stat_subscription - пусто, pg_stat_replication - оказалось что есть еще один процесс, rds репликация, но она вообще up-to-date, в то время как мой консьюмер топчется в лаге. у него flush_lsn, replay_lsn = confirmed_flush_lsn, а sent_lsn, write_lsn - в интервале лага
Так pg_stat_subscription на подписчике надо смотреть.
В любом случае, обновите сначала, заниматься (с существенной вероятностью) поиском давно исправленных bugs как-то совсем неинтересно.
источник

b🍉

baklawan 🍉 in pgsql – PostgreSQL
Yaroslav Schekin
Так pg_stat_subscription на подписчике надо смотреть.
В любом случае, обновите сначала, заниматься (с существенной вероятностью) поиском давно исправленных bugs как-то совсем неинтересно.
дельное замечание, спасибо. а можете еще пожалуйста мой предыдущий вопрос посмотреть? я может вообще заблуждаюсь в вопросах репликации)
источник

VG

Viktor Grigorev in pgsql – PostgreSQL
Alexey Lesovsky
попробуйте выключить параллелизм через max_parallel_workers_per_gather (достаточно релоада), либо дальше через perf смотреть
спасибо, попробую.

perf показывает в топе по overhead hash_search_with_hash_value 11%
источник