Melkij

Вот честно могу ответить - ни малейших представлений как можно абстрактно сказать, сколько памяти займёт client backend процесс базы.
Это будет меняться от:
- очевидно версии базы, плюс от компилятора и настроек сборки
- session_preload_libraries, work_mem (к слову о work_mem - вы знаете, что один запрос может использовать несколько work_mem?), temp_buffers. Да ещё maintenance_work_mem для некоторых операций
- величины системного каталога - как pinned таблиц, так и затем кэшированных при обращениях
- выполняемых ранее запросов. Тот же кэш хранимых процедур у каждого backend свой

Один backend вполне и десятки гб памяти может использовать и такие настройки может иметь смысл делать для, например, построения индекса.

Помимо собственной private памяти на каждое активное соединение всё множество max_connections резервирует себе некоторое место в сегменте разделяемой памяти, независимо от того, сколько соединений вы затем используете.

Чтобы админить калькуляторы и чайники обычно DBA не нанимают. Тем более если на том же самом калькуляторе помимо базы ещё и приложение отъедает непредсказуемо сколько памяти. Чего там от этого 1гб останется? Видимо даже shared_buffers с 128мб поднимать некуда, а то может и уменьшать придётся. Так что по опыту сложно что-то сказать о такой конфигурации.

Скорей всего не трогайте max_connections. Оставьте дефолтные 100.

Правильно ли я понимаю, что пул соединений не помогает в плане экономии оперативной памяти

Смотря какой пул и как работает приложение.
pgbouncer в pool_mode = transaction вполне может свести пару сотен подключений к баунсеру на десяток коннектов в базе. Ну а 10 процессов базы будут использовать наверняка поменьше памяти чем 200.
Для pool_mode = session - да, только сгладить стоимость fork годится.

select day /*, ... */ 
from tablename 
join lateral generate_series(start_date, end_date, interval '1day') as day on true 
where to_char(day, 'Day') = week_day

если в лоб и у вашего week_day (который с весьма не ясной причиной хранится в varchar) написание совпадает с to_char.

физически бэкапить определённые базы

Не сможете.
Ну в смысле скопировать отдельные файлы можете. А вот восстановить потом - нет. Никогда.
Бекапить можно только целиком весь datadir, со всеми симлинками. Правильно объяснив базе что вы её бекапите и соблюдая ожидания базы по методу её бекапа чтобы из этого потом можно было восстановиться.

А директории баз называются идентично полю oid в pg_database

index (func1, func2) - это в корне не то же самое что func1 || func2
Выражения для оператора разные, поэтому индекс отбрасывается как неподходящий.

В общем случае фильтр по выражению может работать по индексу только построенному в точности по такому же выражению.

basebackup - это буквально копирование почти всего из PGDATA тупо на уровне файликов.
Строго в один поток. (ну, на самом деле в отдельном потоке walreceiver ещё если wal method выставлен stream)

Смотрите внимательнее куда упираетесь. Диск на чтение откуда снимаете? Диск куда пишете? Сеть? Одно ядро CPU на базе с которой снимаете? На которую пишете?
Несколько гигабит занять в общем-то не проблема.

СУБД однозначно отвечает, что не согласна с синтаксисом.

Если не читать списки зарезервированных слов - то да, может быть не совсем очевидно почему этот запрос синтаксически неверен. Но тем не менее слово user всё равно зарезервировано и стандартами SQL и конкретной реализацией в postgresql. А потому не может использоваться в качестве unquoted идентификатора.

Я не знаю java, но где вы вообще передаёте 4 параметр в запрос?

Ошибка говорит о том, что java по extended протоколу заявляет, что передаёт данные типа varchar, вместо типа gender. Да, для extended протокола это разные вещи и автоматически менять тип не будем.

Попробуйте так:
VALUES (?,?,?,cast(? as gender))

https://www.postgresql.org/docs/current/runtime-co...

This parameter controls the average number of object locks allocated for each transaction; individual transactions can lock more objects as long as the locks of all transactions fit in the lock table. This is not the number of rows that can be locked; that value is unlimited. The default, 64, has historically proven sufficient, but you might need to raise this value if you have queries that touch many different tables in a single transaction, e.g. query of a parent table with many children.

Не имеет отношения к размерам таблиц. Имеет отношение к размеру внутренней таблицы локов и количеству затронутых объектов (например, таблиц) в транзакции. Строго говоря: максимальное число локов объектов одновременно всеми активными транзакциями.
Не имеет никакого отношения к shared_buffers (не вычитается из него, а прибавляется сверху. shared_buffers - строго буфер страниц, даже без учёта структур данных по управлению этим буфером. Сегмент разделяемой памяти всегда больше shared_buffers) или work_mem или чему-то ещё (кроме как max_connections + max_prepared_transactions). Тем более не имеет никакого отношения к дедлокам.

Дефолтного значения обычно более чем достаточно. Может быть злоупотребляете партицированием.

Если в директории C:\Program Files\PostgreSQL\9.1\data (далее буду называть $PGDATA) лежат директории base, global, pg_xlog и всякое прочее преимущественно с префиксом pg_* - то надежда есть. Если в pg_xlog лежат куча странных файлов, а pg_tblspc пусто либо ссылки из него живые. Сделайте бекап $PGDATA и содержимого pg_tblspc (если там были ссылки).

Затем ставите сервер версии 9.1.24. Настраиваете data_directory смотреть в ваш $PGDATA. Пробуете запустить СУБД и смотрите в лог базы что происходит.

pg_upgrade требует заведомо работающих и корректно остановленных кластеров и старой версии и новой. Откажется работать даже если база была выключена аварийно.

Вам нужен check constraint.

XOR в postgresql вроде нет, так что показывать на пальцах:

alter table tablename add constraint tablename_p1_xor_p2 check((p1 is null and p2 is not null) or (p2 is null and p1 is not null));

Java - это такой специальный язык для генерации километровых backtrace...

Почему получив null value in column violates not-null constraint вы решили, что у вас проблема с подключением к СУБД? Вы пытаетесь вставить NULL в поле отмеченное как NOT NULL. Судя по тексту запроса - у вас не указано default значение для этого поля.

Нет, гарантии нет. Менять привычный 5432 порт у сообщества причин нет. Теоретически поменять дефолтный порт можем, это не так сложно технически - но зачем? Мы не гарантируем совместимость с последующими версиями и вполне можем решить что-нибудь сломать нужное, если сообщество согласится что оно того стоит. Гарантий не дадим, но вполне можно рассчитывать что будет 5432 ещё очень долго использоваться по умолчанию, нет причин его менять и есть веские причины его не менять.

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

--with-pgport=PORTNUM set default port number [5432]

Пока он как-то сам выбирает порт

PostgreSQL не занимается таким. Просто откажется стартовать если не удастся открыть сокет. Номер порта не менялся очень давно, если менялся вообще хоть когда-нибудь от самого основания ещё post-ingres в 198х годах.

Вот сторонние скрипты - те могут иметь какую-нибудь такую логику. Например, пакеты debian/ubuntu при вызове pg_createcluster попробует прописать в конфиге ближайший свободный порт начиная с 5432. Никакой зависимости от версии СУБД нет. Нужен новый кластер? Ок, возьмём ближайший свободный порт и настроим на использование его.

postgres=# CREATE DATABASE joba_finder;
CREATE DATABASE
postgres=# CREATE USER jf_user WITH PASSWORD 'qwerty';
CREATE ROLE
postgres=# \l joba_finder 
                               Список баз данных
     Имя     | Владелец | Кодировка | LC_COLLATE  |  LC_CTYPE   | Права доступа 
-------------+----------+-----------+-------------+-------------+---------------
 joba_finder | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 | 
(1 строка)

postgres=# GRANT ALL PRIVILEGES ON DATABASE joba_finder to jf_user;
GRANT
postgres=# \l joba_finder 
                                   Список баз данных
     Имя     | Владелец | Кодировка | LC_COLLATE  |  LC_CTYPE   |     Права доступа     
-------------+----------+-----------+-------------+-------------+-----------------------
 joba_finder | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 | =Tc/postgres         +
             |          |           |             |             | postgres=CTc/postgres+
             |          |           |             |             | jf_user=CTc/postgres
(1 строка)

postgres=# select version();
                                                version                                                 
--------------------------------------------------------------------------------------------------------
 PostgreSQL 11.2 (Debian 11.2-2) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-2) 8.3.0, 64-bit
(1 строка)

Just works. Настройками это не регулируется, так что проверяйте что вы делаете не так. Может быть не коммитите транзакцию с grant? Не знаю.

Не заметил:

joba_finder-# \l

Внимание на -# так где должен быть =# - метка указывает, что вы начали писать запрос, но не завершили его. psql команды вроде \l при этом всё ещё обрабатываются.

postgres=# select
postgres-# \l joba_finder 
                                   Список баз данных
     Имя     | Владелец | Кодировка | LC_COLLATE  |  LC_CTYPE   |     Права доступа     
-------------+----------+-----------+-------------+-------------+-----------------------
 joba_finder | postgres | UTF8      | ru_RU.UTF-8 | ru_RU.UTF-8 | =Tc/postgres         +
             |          |           |             |             | postgres=CTc/postgres+
             |          |           |             |             | jf_user=CTc/postgres
(1 строка)

postgres-# 1;
 ?column? 
----------
        1
(1 строка)

Как пример psql команды в середине написания select 1;

Возможно ли не встравлять в таблицу записи, которые уже присутствуют в таблице?

Возможно. Если вы этим знанием свой предметной области поделитесь с СУБД и создадите уникальное ограничение. А скорей всего это вовсе натуральный первичный ключ.

on conflict работает как ни удивительно при конфликте уникальности. Поэтому пока у вас никто не гарантирует уникальность данных - on conflict ничего не сделает.