и никакого левенштейна не надо

как?

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

заворачиваешь это в функцию с двумя параметрами (или одним, если по таблице проверяешь)

cut -c8- имя файла | awk '{print $1}' | sort | uniq -c

таблицу предварительно выгрузить в файл

$1 столбец с нумерами

это на каком языке?

Командная строка линукса

Всем привет. У нас случилась беда с pg_wal.

А то у нас тут прям печаль образовалась:
root@mssql-data:/var/lib/postgresql/12/main# du -h --max-depth=1
4.0K    ./pg_dynshmem
4.0K    ./pg_twophase
4.0K    ./pg_stat
632K    ./global
38G     ./pg_wal
))

Как то так

смотрим archive_command и забытые слоты репликации

Ок. Завтра покопаю. Спс. А как-то почистить это потом можно? А то гугл говорит нельзя.

“как” зависит от того “что” у вас там…

Всё-таки решили разобраться, можно ли сделать добавление записей из другого воркера в более элегантном, правильном и оптимальном стиле.
Таблицу message заполняет один воркер, который отправляет пару keyword, message_id в другой воркер. И второй воркер должен создавать следующие записи в базе постгреса:
1. Запись в таблицу type, если её нет.
2. Запись в таблицу keyword, если её нет.
3. Запись в таблицу message-keyword, если её нет.
Проблема заключается в том, что записи добавляются в базу параллельно, и может возникнуть случай, когда на любом из шагов 1-3 словим IntegrityError. В этом случае, необходимо либо пропустить какой-то шаг 1-3 (т. к. данные по этому записи уже есть) и создать недостающие связи, если такие есть, либо отправить задачу на Retry, где в самом начале работы воркер проверяет, существует ли keyword в базе.
В текущей реализации никаких on_conflict_do не используются, а используются savepoint перед каждым из шагов 1-3. Если возникла ошибка, то делаем rollback и идём дальше. Насколько это хорошо или плохо? Как это сделать более правильно? Единственное, что у меня на уме — это то, что необходимо сделать все эти добавления одной транзакцией, потому что в случае неудачи в воркере (хоть данные сейчас и записываются в самом конце работы воркера, но логика работы может измениться в скором времени) данные в базе должны быть в том виде, в котором они были до выполнения задачи.

Если решите транзакции использовать, то надо учитывать то, что все запросы внутри транзакции в рамках одного коннекта надо делать (в пул не возвращать)

Это, если я правильно понял, зависит от pool_mode в pgbouncer?
Точнее нет, не так.
Мы начинаем транзакцию, когда создаётся сессия (в моём случае через sqlalchemy)

Между тем, когда открыл транзакцию и когда её закоммитил или откатил, коннект не закрывай просто. Я об этом