Сергей Соловьев

При установке значит PATH не был обновлен.
Надо найти директорию, в которую установлен postgres и попробовать запустить оттуда.
Возможный путь C:\Program Files\PostgreSQL\%version%\bin:
- %version% - подставляешь свою версию
- Все бинари лежат обычно в /bin директории (pg_ctl, pg_dump, initdb и др.)

После рекомендую обновить PATH - добавить этот путь.

Дополнительно: в настройках pgAdmin можно прописать кастомный путь до постгреса:
File (правый верхний угол) -> Preferences -> Paths -> Binary paths
Возможно после этого и pgAdmin заработает

Условие задачи понял так: надо найти индексы записей, которые образуют окно в котором b04 равны тем, что указаны в массиве.
Записи могут идти в любом порядке, поэтому предположил (из примера), что они должны сравниваться в порядке indx

with window_table as (
        select array_agg(indx) over prev_rows as indexes, 
                   array_agg(b04)  over prev_rows as vals 
        from tb 
        window prev_rows as (order by indx rows between 2 preceding and current row)
) 
select unnest(indexes) 
from window_table 
where vals = ARRAY[60, 119, 58];

Значит есть открытая сессия с этой БД. Закрой ее (например, pg_terminate_backend()) и повтори заново

Судя по всему эта бд/таблицы уже существуют.
Тут 2 варианта:
- Удаляешь БД вручную и запускаешь заново
- Делаешь новый бэкап, но добавляешь флаг --clean (чтобы DROP DATABASE выражение тоже было, т.е. пересоздать) - pg_dumpall --clean > db.out

Делать индексацию ради индексации - плохая затея.
На малом количестве записей она либо заметна не будет, либо планировщик просто не будет его (индекс) использовать.
Когда и на что делать индексы лучше определять:
- Это основной юз. кейс приложения - например поиск нужного документа по номеру ФЗ
- Объемное тестирование показало большую деградацию производительности

Также меня интересует само индексированное поле. Если это просто имя пользователя (Иван, Алексей, Елена), то:
1. Индекс лучше не строить, т.к. селективность будет большой и индекс будет редко использоваться
2. Создать индекс на нормализованное имя - CREATE INDEX name_idx ON users (lower(name));

Но если это username/login (т.е. неизменяемый логин пользователя), то в принципе нормально.

UDPATE posts SET theme = 'IT' WHERE theme = 'it'

Судя по этой статье можно всегда использовать TEXT вместо CHAR(N) и VARCHAR(N), т.к. производительность особо не страдает.

А если самому пойти в документацию, то можно увидеть следующее:

There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.

Т.е. в производительности разницы нет - только в стоимости хранения. (в отличие от других СУБД)

SELECT * FROM todos GROUP BY user_id, completed;

Потому что нельзя передавать название таблицы в качестве параметра - Оно должно быть указано явно и прямо, а параметризация нужна для ПАРАМЕТРОВ.

Либо переделывай, либо вот тут вроде есть решение

тебе просто нужно удалить контейнер, которому примаунчен этот вольюм.
пока контейнер ОСТАНОВЛЕН все ресурсы за ним еще сохраняются

1) Что будет с запросом UPDATE, если исполнение кода ещё не дошло до этого запроса, оно получается будет ещё доступна для запросов из другого кода?

Не понял, что имеется ввиду. Но если это про то - "будут ли видны изменения, которые сделаны до вызова этого UPDATE в транзакции", то это зависит от уровня изоляции других транзакций.
В случае SERIALIZABLE - нет, не увидят.

2) А если функцию sameFunc запустят много юзеров? Получается КАЖДЫЙ юзер будет ждать завершения предыдущих транзакций от всех остальных юзеров?

Так как указана SERIALIZABLE, то да:
- Если конфликтов не будет, т.е. никто не обновлял те же самые записи, то будут ждать
- Если кто-то одновременно обновил одни и те же данные, то будет конфликт транзакции

Стоит еще учесть, что если одна и та же запись обновлена одновременно разными транзакциями, то поздняя транзакция просто заблокируется и будет ждать: либо когда первая закоммит - тогда конфликт транзакции, либо первая выполнит откат и ты продолжишь выполнение
P.S. еще есть таймаут ожидания транзакции

3) А если все запросы в транзакции взаимодействуют только с полями конкретного юзера, то как это нужно реализовать в транзакциях? Вроде как объект транзакции один — сам node.js, который единожды подключается к БД.

А вот тут надо разобраться. Зависит от того как ты работаешь с БД.
Судя по названию ты используешь пул соединений (переменная pool) и каждый раз выполняешь запрос на нем. Я не знаю node.js и фреймворк для БД, который ты используешь, но что-то подсказывает, что на каждый такой .query создается отдельное подключение и выполняется запрос.
Если да, то этот код работать не будет, т.к. ты постоянно открываешь новое соединение, начинаешь транзакцию или запрос и закрываешь соединение. В этом случае, все начавшиеся транзакции завершатся сразу, а запросы, которые должны работать в транзакции будут выполняться сразу.
Чтобы все работало корректно - на каждом вызове этого метода открывай новое соединение и работай с ним. Тогда гонки в коде не будет. (Можно еще использовать пул соединений).

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