vreitech

Никак.

Если очень хотите головной боли и новых аварий по ночам вместо того чтобы спокойно спать - возьмите какой-нибудь autofailover типа patroni и прочих.

Критичная проблема фундаментальна - CAP теорема в целом и последствия split brain в частности.

сейчас в какой то момент при серверном рендеринге некоторые запросы провисают и nginx рвет соединение в итоге часть запросов к сайту падает.

Даже голый инстанс nginx тяжело убить всего-лишь 800 рпс. Пусть это даже будет одноядерное гамно.
Мне кажется, думать о тюнинге самого nginx пока рано, по опыту - 4-5к рпс на 1 ноду nginx не создает никаких проблем для обычного 2х ядерного DO'шного сервака за 15$.

Проблема не веб-сервера, проблема бэкенда, который стоит за ним.

Соединение рвется с кем? То что с клиентом - понятно, какой ответ отдает nginx, наверное 504?
Рвет соединение с клиентом он скорее всего потому-что бэкенд отвалился. Кто отваливается из бэка?
Если с пыхой - ковырять пыху.
Если с нодой - ноду.

Обрывать соединения nginx может по ряду причин:
- connection timeout при общении с бэкендом
- обрыв соединения с бэкендом
- некорректный (ошибочный) ответ бэкенда
- туева хуча ошибок при общении с клиентом (это опускаем)

Обо всем этом nginx успешно пишет в свои логи, посмотрите что там происходит.
Также, сам пых и ноду можно настроить логи на отладку.
У пыхи есть трейсинг слоу-логов, логирование каждого запроса и прочее.

Маны и бубень в руки. Удачи!

Хотите сделать пагинацию правильно - не используйте offset, а передавайте сведения сортировки последнего показанного поста.
https://use-the-index-luke.com/sql/partial-results...
https://use-the-index-luke.com/no-offset

Наверняка видели, когда переходите на следующую страницу (например, лента постов отсортированная по времени публикации), вы вдруг видите те же самые записи что только что видели - просто потому что пока вы читали предыдущую страницу кто-то опубликовал новые посты и offset вас честно сдвинул.

Как я делал на бекенде: передаётся номер страницы n. Так же у меня уже есть константа на количество записей на странице (допустим 10). Далее я делаю выборку от n * 10 элемента до (n + 1) * 10

Этого не может быть, потому что не может быть никогда.
В обоих случаях сервер получит "GET / HTTP/1.x"
Может просто браузер слеш добавляет?

kde
поддержка виртуальных столов есть еще в xfce

unity - это скорее всего результат саботажа конкурента, 'проникли' в стан разработчиков, заняли руководящие роли (тех кто принимает решение о направлении развития) и сломали все что только можно сломать

major версия обязана совпадать, обязаны совпадать ряд флагов компиляции и некоторые настройки.

с centos 7 на убунту 20.04 реплицировать можно, но вы гарантированно попадаете на изменение правил сортировки строк в libc: https://wiki.postgresql.org/wiki/Locale_data_changes
Для переезда на другую ОС годится (подняли реплику, в нужный момент переключили на неё мастер и реиндексировали пострадавшие индексы), для долговременной работы уже не очень вариант.

read -p 'Enter something: ' a
echo $a

Для начала, в postgresql нет типа данных string. (а если это самодельный тип, что postgresql сделать тоже позволяет, то смотреть надо как он реализован у вас)

Для текстовых данных в postgresql есть:
- text. Просто text, без специфических ограничений на содержимое
- varchar - это всё тот же самый text. К varchar можно добавить указание ограничения максимальной длины хранимого текста в символах. Почему это отдельный тип данных? Потому что такого требование стандарта SQL
- char - фиксированный длины (в символах! в байтах они всё равно динамической длины получатся для того же utf8). Смысла его использовать в postgresql, как вы сами процитировали документацию, нет. Зачем он нужен? Потому что описан в стандарте.

В отличии от, например, mysql, для postgresql нет ничего особого в значении 255. Если в определении таблицы видно такое ограничение на 255 символов - обычно это означает именно "никто не обдумывал цель такого ограничения для этого поля, просто какое-то число"

Говоря о выборе между text или varchar(N) - varchar(N) с разумным для этих данных N предпочтительнее для коротких строк, потому что не даст записать 10мб туда где должно быть, например, не более 64 символов (это не совсем шутка, случай из практики). А по ошибке в месте записи дебажить логику приложения куда как проще, чем искать потом откуда такое взялось.

никак

явно указать все нужные таблицы, pg_dump --help