Melkij

Можно, это даже транзакционная команда. Разумеется, до окончания транзакции авторизоваться с именем этого пользователя не получится.

PS: больше одного супера - большой вопрос к организации работы базы

maintainer here.

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

Буквально так и пишется дай messages для который нет вот таких

select ... from messages where not exists (select from comments where comments.message_id = messages.id and comments.author_id = 100);

tldr: WHERE a LIKE concat('%',$1,'%') либо конкатенировать к параметру на стороне приложения.

'%$1%' - это строковой литерал, константа из 4 символов. Внутри литерала никто параметры искать и подставлять не будет. Поэтому в запросе не найдено ни одного места для параметров, а вы передаёте один параметр - что явная ошибка логики программы, об этом и выводится ошибка.

Ни документация ни гитхаб не упоминает поддержку экзотических платформ вроде windows. Только обычный linux.

Попробуйте творчески адаптировать процедуру установки plrust из исходников под вашу платформу (возможно что не получится). Ну или просто поставить обычный linux, например в виртуалке.

Some of the PostgreSQL parameters must hold the same values on the primary and the replicas. For those, values set either in the local patroni configuration files or via the environment variables take no effect. To alter or set their values one must change the shared configuration in the DCS. Below is the actual list of such parameters together with the default values:
max_connections: 100
max_locks_per_transaction: 64
max_worker_processes: 8
max_prepared_transactions: 0
wal_level: hot_standby
track_commit_timestamp: off

https://patroni.readthedocs.io/en/latest/patroni_c...
всё выглядит штатно, как задумано разработчиками patroni

1. запустили намеренно pg_dump с отказом -O - то есть --no-owner
   
2. развернули дамп от супера
   
3. все объекты теперь ожидаемо принадлежат суперу, owner'а же не переносили
   
4. удивляемся, что постороннему пользователю нет прав чтения
   

Что же тут могло пойти не так?

Самое простое для баз с одним пользователем - импортируйте дамп базы от имени этого самого пользователя. Если в базе есть какие-то extension - то сперва их создать от суперпользователя.

Зависит от pool_mode.

В режиме session баунсер прозрачен для приложения: не налагает каких-то явных ограничений на использование, но один клиент к баунсеру = один коннект к базе. Соединение с базой сможет быть передано другому клиенту только после того как предыдущий клиент отключится. Поэтому этот режим используется очень редко.

В режиме transaction пула коннект к базе выдаётся клиенту только на время транзакции. Самый распространённый режим работы, любим именно за то, что сколько бы тысяч коннектов не открыло приложение к баунсеру, на базе открыто небольшое число действительно потребовавшихся соединений.
Но этот режим пула налагает ограничения на работу приложения. Вы не сможете нормально использовать ничего, что меняет состояние коннекта, потому что следующий ваш запрос с высокой вероятностью попадёт в другой коннект. То есть курсоры, временные таблицы, set (кроме set local), prepared statements (где parse, bind и execute могут разойтись по 3 разным коннектам)

С prepared statements в transaction pool mode с недавних пор может помочь настройка max_prepared_statements, но только если prepare и deallocate выполняются именно командами протокола, но не SQL запросами. Тут многие широкоиспользуемые библиотеки оказались в пролёте.

text и varchar - это одно и то же на уровне реализации postgresql.

varchar с каким-то разумным ограничением (не бессмысленный взятый с потолка 255 везде, а разумный для этого конкретного поля) тем не менее смысл имеет: куда проще найти ошибку в месте записи данных, чем потом искать, откуда в поле обычно содержащем до 30 символов взялось 10 мегабайт текста (история из практики, да)

Про char ограничусь цитатой письма Tom Lane

Type character(N) is a hangover from the days of punched cards. Don't use it.

Просто забудьте про такой тип данных. Он не только бесполезен, но и вреден.

Нет, ни одно из утверждений не является верным.

btree индекс - это структура, располагающаяся отдельно, сбоку, от таблицы. Порядок данных в таблице никак не меняется от создания индекса.
Индекс btree(a,b,c) и три индекса btree(a), btree(b), btree(c) - разные вещи.

Максимум INT_MAX / 2 числа блоков, что при обычном размере блока в 8кб будет равняться лимиту до 8TiB.

melkij=> set temp_buffers to '8192GB';
ERROR:  1073741824 8kB is outside the valid range for parameter "temp_buffers" (100 .. 1073741823)
melkij=> set temp_buffers to '8191GB';
SET

Действует независимо для каждого процесса базы. При max_connection = 100 каждый из этих 100 процессов имеет возможность выделить по столько памяти для хранения блоков временных таблиц этой сессии.