Ошибка при открытии базы данных postgres - Ремонт и установка крупной бытовой техники

I have a problem to connect server for Postgres after I updated my windows.Before I update there is no problem to open the database. My database in Postgres also gone. When I want to create my new database it show this error:

Unable to connect to server: could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host «localhost» (::1) and accepting TCP/IP connections on port 5432? could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host «localhost» (127.0.0.1) and accepting TCP/IP connections on port 5432?

asked Nov 10, 2016 at 16:23

On windows, Just go to the ‘Services’. Start/Restart the postgresql-X64 service. It worked for me as my service was in stopped state somehow.

answered Feb 23, 2020 at 7:06

gagan chhabragagan chhabra

1,3151 gold badge8 silver badges9 bronze badges

There are two items to configure if your server isn’t on localhost:

find your postgresql.conf and add your server’s public IP address to the end of the setting listen_addresses (separate multiple entries by commas); uncomment the line if it is commented out (e.g. with ‘#’)
add a line to pg_hba.conf containing your client’s IP address — you may copy the line containing 127.0.0.1 and change only the IP address

On Ubuntu, these files are in /etc/postgresql/<version>/main/.

answered Mar 14, 2017 at 1:12

In my case I couldnt’ open the pgAdmin4, for some reason. I use Postgresql 10 and pgAdmin4

The port in the postgresql.conf was not the same as in the pgAdmin4 —> postgreSQL 10 —> properties —> Connection —> port.

I fixed it and it worked. Check if those 2 are in line.

answered Sep 12, 2020 at 13:55

First press win key+R
Search for services.msc
A window will open in that find postgresql-x64-13 and open that, in that tab click start option
For me its works perfectly.

answered May 31, 2021 at 5:03

VADHANVADHAN

2213 silver badges2 bronze badges

Go to PgAdmin
Right click on PostgreSQL
3.Choose properties
At the top, select connection
Try changing the port from 5433 to 5432 or vice versa.

And re-enter.

answered May 15, 2021 at 17:27

Faced this problem immediately after installing on Windows. At startup the pgAdmin gave this error which means that the server is not running. For me the solution was: Start -> Control panel -> Administration -> Services -> postgresql-x64-12 — start or restart

answered Aug 7, 2020 at 21:49

Tim UzlovTim Uzlov

1712 silver badges6 bronze badges

On windows, Just go to the ‘Services’. Start/Restart the postgresql-X64 service. It worked for me as my service was in stopped state somehow.

worked for me

answered Sep 10, 2020 at 18:00

devyan91devyan91

791 silver badge6 bronze badges

This happened because I installed two versions of Postgres (v12 and v13). Psql 12 was installed later so got the port 5433. I needed to use Postgres 12. To fix this particular case:

Go to Program Files/Postgres/<required_version>/data

Open the postgresql.conf file

Search for Port and change the port number to 5432.
Open Windows Services (Press Cmd + R then type services.msc)
Stop the service for the version you don’t want (You can stop it permanentally from the Right Click > Properties menu.)
Start the service for the version you want.

answered Aug 7, 2021 at 14:30

Nitin NainNitin Nain

4,8721 gold badge38 silver badges51 bronze badges

I think the problem is with your server listening to default public IP address.
For example in the PostgreSQL package, your sever is set to listen to localhost as default public address which when you launch/ run database, the address might be something like ‘127.0.0.1’

To fix you can try change localhost to ‘‘ as in «listen_addresses = ‘‘».

As seen as "listen_addresses = 'localhost'" under «Connection Settings» in the postgresql.conf file.

Also to access your postgresql.conf file, go to:

On Windows, the file is in /Program Files/PostgreSQL/<version>/share/.
On Ubuntu, these files are in /etc/postgresql/<version>/main/.

P.S: Changing the defaults ‘localhost’; to ‘*’ will let your server listen to any public database address either «localhost, 127.0.0.1 etc.

I know you might have fix this, just for others that might run into the same issue in the future. Hope it was helpful

answered Jul 31, 2019 at 14:41

goto service and start postgresql-x64-10 service

steps

run -> services.msc -> find postgresql-x64-10 -> start the service
services image

answered Mar 12, 2021 at 14:33

This is a note for a normal user. If using an official installer, it should have a built-in service,

Win+R and type services.msc
Search Postgres service based on the version installed, e.g., «postgresql-x64-13 - PostgreSQL Server 13«
Click stop, start, or restart the service option
If you don’t see start/stop or if these buttons are disabled, then double-click on the PostgreSQL and change startup type to automatic and click on start. This will start the PostgreSQL every time automatically whenever you start your system.

answered Jul 6, 2021 at 2:54

Manoj SwamiManoj Swami

672 silver badges12 bronze badges

I had the same issue, so, I uninstalled postgres. And during reinstallation I noticed the error:
"Failed to load SQL modules into the database cluster"
And:
"Problem running post installation step.Installition may not complete correctly. Error reading file C:/Program Files/PostgreSQL/14/data/postgresql.conf".

I cancelled the installation and then tried again, but with a plain-text password this time, and it worked. It turned out that the special characters in my password were the problem.

ouflak

2,43810 gold badges43 silver badges49 bronze badges

answered Oct 1, 2021 at 14:48

Solutions:

Open Services and make sure that postgresql-x64-14 is running.
Go to C:Program FilesPostgreSQL14data and open postgresql.conf with notepad, find and change port to e.g 5432 and after that open Services and restart postgresql-x64-14.

answered Apr 11, 2022 at 16:06

MaceMace

866 bronze badges

I got this error message when I moved my database to another computer.

I also got some error messages when starting the server first with

pg_ctl -D /wherever/your/database/is start

which were

pg_ctl: another server might be running; trying to start server anyway
server starting

DETAIL: File «/wherever/your/database/is/PG_VERSION» does not contain valid data.

HINT: You might need to initdb.

In my case rather than running initdb this command actually fixed the issue

pg_ctl -D /wherever/your/database/is restart

answered May 10, 2018 at 13:42

uosjeaduosjead

4166 silver badges5 bronze badges

You might have changed the permissions of the ‘PostgreSQL 12’ in ‘services.msc’. Or maybe it is not started and you are trying to start the server when Postgre 12 is not running.

Try these:

Try to start the ‘PostgreSQL 12’ in ‘services.msc’ manually.
Try restarting your PC
If nothing helps, try reinstalling PostgreSQL (pgAdmin 4) from the scratch.

answered Mar 30, 2021 at 12:18

Go to C:Program FilesPostgreSQL13data, edit postgresql.conf with notepad.

Change:

#port = 54XX

To:

port = 54XX

(change requires restart)

restart service at «service system» on window.

Tony Joseph

1,7822 gold badges16 silver badges17 bronze badges

answered Apr 20, 2021 at 17:54

When I run psql, it gave me the same error, and it was because I changed the port while setting Postgres in the installation process.

I had to change back to the default port 5432 in PostgreSQL.conf (which can be found in the data directory) i.e

C:Program FilesPostgreSQL14data>

The problem is no more!

answered Jul 19, 2022 at 15:19

Using psql with single quotes fails:

psql -c 'Select version();' 'postgresql://username:password@db.abcdefghi.ap-southeast-2.rds.amazonaws.com:8080/the_db'

psql: could not connect to server: Connection refused
(0x0000274D/10061)
Is the server running on host «localhost» (::1) and accepting
TCP/IP connections on port 5432? could not connect to server: Connection refused (0x0000274D/10061)
Is the server running on host «localhost» (127.0.0.1) and accepting
TCP/IP connections on port 5432?

Using double quotes works:

psql -c "Select version();" "postgresql://username:password@db.abcdefghi.ap-southeast-2.rds.amazonaws.com:8080/the_db"

PostgreSQL 10.14 on x86_64-pc-linux-gnu, compiled by x86_64-unknown-linux-gnu-gcc (GCC) 4.9.4, 64-bit
(1 row)

answered Jul 14, 2021 at 1:40

Jeremy ThompsonJeremy Thompson

59.7k32 gold badges183 silver badges308 bronze badges

After a wasting 3-4 hrs i find the solution something like this

First set path in enviroment variable.And then make port and psql connecting same i.e 5432 or 5433

answered Sep 18, 2021 at 3:21

If you newly installed the pgAdmin, and you did not remember to install PostgreSQL at that time, you get that error. Make sure you install both pgAdmin And PostgreSQL.

answered Jan 6, 2022 at 11:14

For me I was getting this error and unable to open the server in PgAdmin is because I very often forgot to start the server, one for the way you can start the server with is by running this commands on cmd, make sure you provide the right path

cd "C:Program FilesPostgreSQL14bin"
pg_ctl -D "C:Program FilesPostgreSQL14data" start

answered Apr 13, 2022 at 6:42

DINA TAKLITDINA TAKLIT

5,8629 gold badges61 silver badges72 bronze badges

And so for the new arrivals. If you are using pgAdmin and a Windows operating system, do some research to resolve the issue.

Make sure you have Postgresql installed or active

To do this, go to windows services (press Cmd + R and run the services.msc command)
Look in the list for a service called postgresql-x{BIT}-{Version}-PostgreSQL Server {Version}

Solution 1: If you don’t find the service, then PostgreSQL is not installed or has been uninstalled, install it again.

Solution 2: If you find the service, but you still can’t log in, then most likely the service is not active for some reason, select the service and click the Start or Restart button

answered Mar 24, 2022 at 4:41

Harvey DentHarvey Dent

1,8763 gold badges8 silver badges15 bronze badges

Unable to connect to server: could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host «localhost» (::1) and accepting TCP/IP connections on port 5432? could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host «localhost» (127.0.0.1) and accepting TCP/IP connections on port 5432?

asked Nov 10, 2016 at 16:23

On windows, Just go to the ‘Services’. Start/Restart the postgresql-X64 service. It worked for me as my service was in stopped state somehow.

answered Feb 23, 2020 at 7:06

gagan chhabragagan chhabra

1,3151 gold badge8 silver badges9 bronze badges

There are two items to configure if your server isn’t on localhost:

find your postgresql.conf and add your server’s public IP address to the end of the setting listen_addresses (separate multiple entries by commas); uncomment the line if it is commented out (e.g. with ‘#’)
add a line to pg_hba.conf containing your client’s IP address — you may copy the line containing 127.0.0.1 and change only the IP address

On Ubuntu, these files are in /etc/postgresql/<version>/main/.

answered Mar 14, 2017 at 1:12

In my case I couldnt’ open the pgAdmin4, for some reason. I use Postgresql 10 and pgAdmin4

The port in the postgresql.conf was not the same as in the pgAdmin4 —> postgreSQL 10 —> properties —> Connection —> port.

I fixed it and it worked. Check if those 2 are in line.

answered Sep 12, 2020 at 13:55

First press win key+R
Search for services.msc
A window will open in that find postgresql-x64-13 and open that, in that tab click start option
For me its works perfectly.

answered May 31, 2021 at 5:03

VADHANVADHAN

2213 silver badges2 bronze badges

Go to PgAdmin
Right click on PostgreSQL
3.Choose properties
At the top, select connection
Try changing the port from 5433 to 5432 or vice versa.

And re-enter.

answered May 15, 2021 at 17:27

answered Aug 7, 2020 at 21:49

Tim UzlovTim Uzlov

1712 silver badges6 bronze badges

On windows, Just go to the ‘Services’. Start/Restart the postgresql-X64 service. It worked for me as my service was in stopped state somehow.

worked for me

answered Sep 10, 2020 at 18:00

devyan91devyan91

791 silver badge6 bronze badges

This happened because I installed two versions of Postgres (v12 and v13). Psql 12 was installed later so got the port 5433. I needed to use Postgres 12. To fix this particular case:

Go to Program Files/Postgres/<required_version>/data

Open the postgresql.conf file

Search for Port and change the port number to 5432.
Open Windows Services (Press Cmd + R then type services.msc)
Stop the service for the version you don’t want (You can stop it permanentally from the Right Click > Properties menu.)
Start the service for the version you want.

answered Aug 7, 2021 at 14:30

Nitin NainNitin Nain

4,8721 gold badge38 silver badges51 bronze badges

To fix you can try change localhost to ‘‘ as in «listen_addresses = ‘‘».

As seen as "listen_addresses = 'localhost'" under «Connection Settings» in the postgresql.conf file.

Also to access your postgresql.conf file, go to:

On Windows, the file is in /Program Files/PostgreSQL/<version>/share/.
On Ubuntu, these files are in /etc/postgresql/<version>/main/.

P.S: Changing the defaults ‘localhost’; to ‘*’ will let your server listen to any public database address either «localhost, 127.0.0.1 etc.

I know you might have fix this, just for others that might run into the same issue in the future. Hope it was helpful

answered Jul 31, 2019 at 14:41

goto service and start postgresql-x64-10 service

steps

run -> services.msc -> find postgresql-x64-10 -> start the service
services image

answered Mar 12, 2021 at 14:33

This is a note for a normal user. If using an official installer, it should have a built-in service,

Win+R and type services.msc
Search Postgres service based on the version installed, e.g., «postgresql-x64-13 - PostgreSQL Server 13«
Click stop, start, or restart the service option
If you don’t see start/stop or if these buttons are disabled, then double-click on the PostgreSQL and change startup type to automatic and click on start. This will start the PostgreSQL every time automatically whenever you start your system.

answered Jul 6, 2021 at 2:54

Manoj SwamiManoj Swami

672 silver badges12 bronze badges

I cancelled the installation and then tried again, but with a plain-text password this time, and it worked. It turned out that the special characters in my password were the problem.

ouflak

2,43810 gold badges43 silver badges49 bronze badges

answered Oct 1, 2021 at 14:48

Solutions:

Open Services and make sure that postgresql-x64-14 is running.
Go to C:Program FilesPostgreSQL14data and open postgresql.conf with notepad, find and change port to e.g 5432 and after that open Services and restart postgresql-x64-14.

answered Apr 11, 2022 at 16:06

MaceMace

866 bronze badges

I got this error message when I moved my database to another computer.

I also got some error messages when starting the server first with

pg_ctl -D /wherever/your/database/is start

which were

pg_ctl: another server might be running; trying to start server anyway
server starting

DETAIL: File «/wherever/your/database/is/PG_VERSION» does not contain valid data.

HINT: You might need to initdb.

In my case rather than running initdb this command actually fixed the issue

pg_ctl -D /wherever/your/database/is restart

answered May 10, 2018 at 13:42

uosjeaduosjead

4166 silver badges5 bronze badges

You might have changed the permissions of the ‘PostgreSQL 12’ in ‘services.msc’. Or maybe it is not started and you are trying to start the server when Postgre 12 is not running.

Try these:

Try to start the ‘PostgreSQL 12’ in ‘services.msc’ manually.
Try restarting your PC
If nothing helps, try reinstalling PostgreSQL (pgAdmin 4) from the scratch.

answered Mar 30, 2021 at 12:18

Go to C:Program FilesPostgreSQL13data, edit postgresql.conf with notepad.

Change:

#port = 54XX

To:

port = 54XX

(change requires restart)

restart service at «service system» on window.

Tony Joseph

1,7822 gold badges16 silver badges17 bronze badges

answered Apr 20, 2021 at 17:54

When I run psql, it gave me the same error, and it was because I changed the port while setting Postgres in the installation process.

I had to change back to the default port 5432 in PostgreSQL.conf (which can be found in the data directory) i.e

C:Program FilesPostgreSQL14data>

The problem is no more!

answered Jul 19, 2022 at 15:19

Using psql with single quotes fails:

psql -c 'Select version();' 'postgresql://username:password@db.abcdefghi.ap-southeast-2.rds.amazonaws.com:8080/the_db'

psql: could not connect to server: Connection refused
(0x0000274D/10061)
Is the server running on host «localhost» (::1) and accepting
TCP/IP connections on port 5432? could not connect to server: Connection refused (0x0000274D/10061)
Is the server running on host «localhost» (127.0.0.1) and accepting
TCP/IP connections on port 5432?

Using double quotes works:

psql -c "Select version();" "postgresql://username:password@db.abcdefghi.ap-southeast-2.rds.amazonaws.com:8080/the_db"

PostgreSQL 10.14 on x86_64-pc-linux-gnu, compiled by x86_64-unknown-linux-gnu-gcc (GCC) 4.9.4, 64-bit
(1 row)

answered Jul 14, 2021 at 1:40

Jeremy ThompsonJeremy Thompson

59.7k32 gold badges183 silver badges308 bronze badges

After a wasting 3-4 hrs i find the solution something like this

First set path in enviroment variable.And then make port and psql connecting same i.e 5432 or 5433

answered Sep 18, 2021 at 3:21

If you newly installed the pgAdmin, and you did not remember to install PostgreSQL at that time, you get that error. Make sure you install both pgAdmin And PostgreSQL.

answered Jan 6, 2022 at 11:14

cd "C:Program FilesPostgreSQL14bin"
pg_ctl -D "C:Program FilesPostgreSQL14data" start

answered Apr 13, 2022 at 6:42

DINA TAKLITDINA TAKLIT

5,8629 gold badges61 silver badges72 bronze badges

And so for the new arrivals. If you are using pgAdmin and a Windows operating system, do some research to resolve the issue.

Make sure you have Postgresql installed or active

To do this, go to windows services (press Cmd + R and run the services.msc command)
Look in the list for a service called postgresql-x{BIT}-{Version}-PostgreSQL Server {Version}

Solution 1: If you don’t find the service, then PostgreSQL is not installed or has been uninstalled, install it again.

Solution 2: If you find the service, but you still can’t log in, then most likely the service is not active for some reason, select the service and click the Start or Restart button

answered Mar 24, 2022 at 4:41

Harvey DentHarvey Dent

1,8763 gold badges8 silver badges15 bronze badges

↓
Содержание статьи
↓

	psql command not found
	ERROR: character with byte sequence 0xd0 0x9a in encoding «UTF8» has no equivalent in encoding «WIN1252»
	ERROR: database «db» is being accessed by other users
	FATAL password authentication failed for user postgres
	ERROR: could not open file «/home/user…» for reading: Permission denied
	ERROR: COPY quote must be a single one-byte character
	ERROR: date/time field value out of range
	Job for postgresql.service failed because the control process exited with error code
	psql: could not connect to server: No such file or directory
	pg_basebackup: could not connect to server: No route to host
	Failed to stop postgresql.service: Unit postgresql.service not loaded
	ERROR: WAL level not sufficient for making an online backup
	NOTICE: WAL archiving is not enabled

Ошибки

psql command not found

Вы хотите запустить Postgres скрипт из bash

andrey@olegovich-10:/mnt/c/Users/olegovich$ psql -h localhost -p 5432 -U andrei

но получаете эту ошибку

-bash: psql: command not found

Это значит, что путь до Postgres не прописан в $PATH

Чтобы узнать, что прописано в $PATH достаточно сделать

echo $PATH

/home/andrei/bin:/home/andrei/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Program Files (x86)/Common Files/Oracle/Java/javapath_target_1128437:/mnt/c/ProgramData/Oracle/Java/javapath_target_5252250:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/Program Files/OpenVPN/bin:/mnt/c/Program Files (x86)/Microsoft SQL Server/Client SDK/ODBC/130/Tools/Binn:/mnt/c/Program Files (x86)/Microsoft SQL Server/140/Tools/Binn:/mnt/c/Program Files (x86)/Microsoft SQL Server/140/DTS/Binn:/mnt/c/Program Files (x86)/Microsoft SQL Server/140/Tools/Binn/ManagementStudio:/mnt/c/Program Files/MiKTeX 2.9/miktex/bin/x64:/mnt/c/Users/andreyolegovich_ru/Documents/Software/axis2-1.6.2:/mnt/c/Users/andreyolegovich_ru/Documents/Software/axis2-1.6.2/bin:/mnt/c/Windows/System32/OpenSSH:/mnt/c/Program Files/TortoiseSVN/bin:/mnt/c/Program Files/Microsoft SQL Server/Client SDK/ODBC/130/Tools/Binn:/mnt/c/Program Files/Microsoft SQL Server/140/Tools/Binn:/mnt/c/Program Files/Microsoft SQL Server/140/DTS/Binn:/mnt/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/DAL:/mnt/c/Program Files/Intel/Intel(R) Management Engine Components/DAL:/mnt/c/Program Files/TortoiseGit/bin:/mnt/c/Program Files/Git/cmd:/mnt/c/Program Files/nodejs:/mnt/c/Program Files/Intel/WiFi/bin:/mnt/c/Program Files/Common Files/Intel/WirelessCommon:/mnt/c/Program Files/PuTTY:/mnt/c/Users/andreyolegovich_ru/AppData/Local/Continuum/anaconda3:/mnt/c/Users/andreyolegovich_ru/AppData/Local/Continuum/anaconda3/Library/mingw-w64/bin:/mnt/c/Users/andreyolegovich_ru/AppData/Local/Continuum/anaconda3/Library/bin:/mnt/c/Users/andreyolegovich_ru/AppData/Local/Continuum/anaconda3/Scripts:/mnt/c/Users/andreyolegovich_ru/AppData/Local/Programs/Python/Python36/Scripts:/mnt/c/Users/andreyolegovich_ru/AppData/Local/Programs/Python/Python36:/mnt/c/Users/andreyolegovich_ru/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/andreyolegovich_ru/AppData/Local/atom/bin:/mnt/c/Users/andreyolegovich_ru/AppData/Local/Programs/Python/Python36-32:/mnt/c/Users/andreyolegovich_ru/AppData/Local/Programs/Python/Python36-32/Scripts:/mnt/c/Program Files (x86)/Nmap:/mnt/c/Program Files (x86)/Mozilla Firefox:/mnt/c/Users/andreyolegovich_ru/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/andreyolegovich_ru/AppData/Local/Programs/Fiddler:/mnt/c/Program Files/JetBrains/PyCharm Community Edition 2018.3.2/bin:/mnt/c/Users/andreyolegovich_ru/AppData/Roaming/npm:/mnt/c/Program Files/Intel/WiFi/bin:/mnt/c/Program Files/Common Files/Intel/WirelessCommon:/mnt/c/Users/andreyolegovich_ru/AppData/Local/Programs/Microsoft VS Code/bin:/snap/bin

ERROR: character with byte sequence 0xd0 0x9a in encoding «UTF8»

has no equivalent in encoding «WIN1252»

Скорее всего Вы создали базу данных, и даже смогли туда что-то импортировать, например, из .csv файла.

Но сделать SELECT * FROM table; уже не получается, потому что кодировка базы и кодировка файла не совпадают.

Возможно, Вы уже попробовали явно указать SET CLIENT_ENCODING TO ‘utf8’; при импорте файла. Но так как кодировка WIN1252
— это кодировка БД, способ не сработал.

Нужно привести файл и БД к одной кодировке — пересоздайте БД в utf8, например.

Как проверить кодировки я писал выше —

Проверка кодировок БД

Как указать кодировку при создании БД —

Создание БД

ERROR: database «db» is being accessed by other users

Если Вы делаете DROP DATABASE db; и получаете

ERROR: database «db» is being accessed by other users

DETAIL: There are 2 other sessions using the database.

Значит где-то ещё не закрыто подключение к БД. Например, Вы открывали её через pgAdmin.

Нужно найти это подключение и закрыть

FATAL password authentication failed for user postgres

Если вы логинитесь в pgAdmin, но не помните пароль — его можно поменять через терминал

sudo su — postgres

psql

postgres=# ALTER USER postgres PASSWORD ‘новый_пароль’;

ALTER ROLE

ERROR: could not open file «/home/user…» for reading: Permission denied

Если вы пытаетесь прочитать из файла, а получаете

ERROR: could not open file «/home/user/file.csv» for reading: Permission denied
HINT: COPY FROM instructs the PostgreSQL server process to read a file. You may want a client-side facility such as psql’s copy. SQL state: 42501

Значит у postgres недостаточно прав для чтения из файла. Простое добавление прав на чтение вроде

chmod +r file.csv

Проблему, скорее всего, не решит.

Как вариант — предлагаю переместить нужный файл в директорию /tmp

cp /home/user/file.csv /tmp

ERROR: COPY quote must be a single one-byte character

Если вы пытаетесь прочитать из файла, а получаете

ERROR: COPY quote must be a single one-byte character

SQL state: 0A000

Скорее всего присутствует какой-то лишний символ в QUOTE, например

QUOTE ‘»‘

Замените на

QUOTE ‘»‘

ERROR: date/time field value out of range

Если вы пытаетесь прочитать из .csv файла, а получаете

ERROR: date/time field value out of range: «» HINT: Perhaps you need a different «datestyle» setting. CONTEXT: «» SQL state: 22008

Скорее всего ваш текущий datestyle не совпадает с тем, который используется в .csv файле.

datestyle — это порядок записи даты. Может быть День — Месяц — Год (DDMMYYYY), Год — Месяц — День (YYYYMMDD) или,
например американский стиль Месяц — День — Год (MMDDYYYY)

Это всё актуально если тип столбца указан как дата date. Можно изменить тип на char тогда datestyle уже не нужно настраивать.

Стилей много и если они не совпадают — получается что месяц принимает значение больше 12.

Как вариант — можно перед выполнение скрипта временно изменить свой datestyle.

Например, если нужно импортировать данные из .csv с американским стилем — перед импортом добавьте

set datestyle to «US»;

psql: could not connect to server: No such file or directory

Если вы выполнили

psql

И получили ошибку

psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket «/var/run/postgresql/.s.PGSQL.5432»?

Очень часто данная ошибка возникает вследствии того, что не была инициализирована база
данных.

Выполните

postgresql-setup initdb

Initializing database … OK

pg_basebackup: could not connect to server: could not connect to server: No route to host

Если вы пытаетесь сделать реплику

pg_basebackup -h 192.168.56.109 -U repluser -D /var/lib/pgsql/data —xlog-method=stream

pg_basebackup: could not connect to server: could not connect to server: No route to host
Is the server running on host «192.168.56.109» and accepting
TCP/IP connections on port 5432?

На мастере

sudo firewall-cmd —zone=public —add-port=5432/tcp —permanent

success

sudo firewall-cmd —reload

success

sudo firewall-cmd —list-ports

3389/tcp 5432/tcp

Failed to stop postgresql.service: Unit postgresql.service not loaded

Причин может быть много но среди новичков самая распространённая — попытка остановить postgresql
из под пользователя postges

Например, в моём терминале я по приглашению bash-4.2$ вижу, что зашёл как postgres

Нужно выполнить

exit

Приглашение изменится на

[andrei@localhost ~]$

И затем уже можно останавливать сервер

sudo systemctl stop postgresql

sudo systemctl status postgresql

● postgresql.service — PostgreSQL database server
Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled; vendor preset: disabled)
Active: inactive (dead)

Jun 09 12:20:24 localhost.localdomain systemd[1]: Unit postgresql.service entered failed state.
Jun 09 12:20:24 localhost.localdomain systemd[1]: postgresql.service failed.
Jun 09 12:21:59 localhost.localdomain systemd[1]: Starting PostgreSQL database server…
Jun 09 12:22:00 localhost.localdomain systemd[1]: Started PostgreSQL database server.
Jun 10 19:10:02 localhost.localdomain systemd[1]: Stopping PostgreSQL database server…
Jun 10 19:10:03 localhost.localdomain systemd[1]: Stopped PostgreSQL database server.
Jun 10 22:14:18 localhost.localdomain systemd[1]: Starting PostgreSQL database server…
Jun 10 22:14:19 localhost.localdomain systemd[1]: Started PostgreSQL database server.
Jun 11 10:11:15 localhost.localdomain systemd[1]: Stopping PostgreSQL database server…
Jun 11 10:11:16 localhost.localdomain systemd[1]: Stopped PostgreSQL database server.

ERROR: WAL level not sufficient for making an online backup

Вы хотите настроить онлайн бэкап, например с помощью команды

-bash-4.2$ psql -c «SELECT pg_start_backup(‘replbackup’);»

Но получаете ошибку

ERROR: WAL level not sufficient for making an online backup

HINT: wal_level must be set to «archive» or «hot_standby» at server start.

Нужно узнать расположение конфигурационного файла

postgresql.conf

-bash-4.2$ su — postgres -c «psql -c ‘SHOW config_file;’»

Password:
config_file
————————————-
/var/lib/pgsql/data/postgresql.conf
(1 row)

vi /var/lib/pgsql/data/postgresql.conf

Нужно установить wal_level = hot_standby

NOTICE: WAL archiving is not enabled

Вы заканчиваете бэкап, например с помощью команды

psql -c «SELECT pg_stop_backup();»

Но получаете предупреждение

NOTICE: WAL archiving is not enabled; you must ensure that all required WAL segments are copied through other means to complete the backup

Ошибка формата потока — одна из самых неприятных ошибок в работе 1С и вызывает панический ужас у многих администраторов и пользователей данной учетной системы. Ее появление обычно говорит о серьезных повреждениях базы данных и, чаще всего, наиболее верным решением будет восстановить базу из резервной копии. В случаях, когда это нежелательно или невозможно придется заняться восстановлением базы, но большинство инструкций в сети рассматривают данный вопрос только на примере MS SQL Server, а PostgreSQL если и касаются, то очень вскользь. Поэтому в данной статье мы постараемся исправить данный пробел.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Начнем с того, что именно обозначает эта ошибка. Разработчики немногословны, никаких подробностей сообщение об ошибке не содержит:

Столь же скупа и информация для технической поддержки:

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

К возникновению данной ошибки приводит повреждение основной конфигурации информационной базы. Реже — кеша конфигурации информационной базы, в последнем случае устранить ошибку можно путем очистки кеша, для этого можете воспользоваться нашей утилитой 1:Tools (кто хочет поддержать нас — может скачать ее по ссылке с Инфостарта)

1:Tools (Зеркало на Инфостарте)
MD5: 448277422B59EFA426CC51E4F3A52F53

В остальных случаях придется заниматься восстановлением непосредственно базы. В этом месте мы сразу внесем ясность и разделим сущности: информационная база 1С — это хранилище данных на уровне логики 1С:Предприятия которое описывается конфигурацией информационной базы. Т.е. именно здесь содержатся документы, справочники, регистры и т.д. и т.п., а повреждение конфигурации информационной базы делает невозможной работу с ними на этом уровне абстракции. База данных СУБД — это набор таблиц в которых хранятся как данные, так и конфигурация информационной базы 1С.

Повреждение основной конфигурации информационной базы происходит именно на уровне логики 1С:Предприятия, база данных СУБД остается работоспособной и не содержит ошибок с точки зрения СУБД. Если это не так, то мы будем иметь дело с повреждением самой базы данных СУБД, а это уже совсем иная ситуация.

В зависимости от того, какая именно часть конфигурации ИБ оказалась повреждена база может не загружаться в обычном режиме, но загружаться в Конфигуратор, либо вообще не загружаться никак. Если доступен режим конфигуратора, то можно попробовать снять базу с поддержки и загрузить в нее исправную конфигурацию из файла, в некоторых случаях это приведет к успеху, в других может потребоваться сначала выявить и удалить сбойный элемент метаданных.

Все это достаточно сложно и не всегда приносит требуемый результат, поэтому проще и надежнее заменить конфигурацию информационной базы на заведомо исправную используя инструменты СУБД, в нашем случае PostgreSQL. В зависимости от используемой ОС (Windows или Linux) некоторые аспекты работы с PostgreSQL могут отличаться и это будет оговорено отдельно, в остальных случаях указанные команды применяются вне зависимости от платформы.

Перед тем как начинать работу с PostgreSQL в Linuх последовательно повысим свои права для суперпользователя и затем войдем в систему от имени пользователя postgres:

sudo -s
su postgres

Если утилита sudo не установлена (такой вариант может быть в Debian), то:

su -
su postgres

В первом случае вам потребуется ввести пароль от текущей учетной записи, во втором — от учетной записи суперпользователя (root).

Затем обязательно сделаем копию информационной базы средствами СУБД. Получить список баз данных в кластере СУБД можно командой:

psql -l

В Windows вам потребуется ввести пароль пользователя postgres.

Выяснив имя необходимой базы данных выгрузим ее дамп командой:

#Linux
pg_dump basename > ~/basename.psql#Windows
pg_dump basename > D:backupbasename.psql

Где basename — имя нужной базы данных. Обратите внимание, что в Windows мы можем явно задать путь выгрузки дампа, а в Linux выгружаем его в домашнюю директорию пользователя postgres, т.е. /var/lib/postgresql.

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

После чего откроем интерактивный терминал PostgreSQL в котором будем производить все последующие действия:

psql

В Windows вы можете получить сообщение:

ПРЕДУПРЕЖДЕНИЕ: Кодовая страница консоли (866) отличается от основной
          страницы Windows (1251).
          8-битовые (русские) символы могут отображаться некорректно.

В этом случае выполните:

 ! chcp 1251

Теперь подключимся к исправной базе:

с newbasename

где newbasename — имя исправной базы данных. При этом в строке приглашения появится имя подключенной базы.

Из нее мы выгрузим таблицу config в которой находится основная конфигурация информационной базы.

#Linux
COPY config TO '/var/lib/postgresql/config_OK.txt';#Windows
COPY config TO 'D:/backup/config_OK.txt';

Обратите внимание, при указании пути для операционной системы Windows вы также должны использовать прямой, а не обратный слеш. Также служба СУБД должна иметь права на запись в целевую аудиторию, проще всего это сделать выдав полные разрешения для пользователя Все.

Переподключимся к поврежденной базе:

с basename

На всякий случай, также сохраним содержимое таблицы config:

#Linux
COPY config TO '/var/lib/postgresql/config_ERR.txt';#Windows
COPY config TO 'D:/backup/config_ERR.txt';

После чего очистим сбойную таблицу:

DELETE FROM config;

И загрузим в нее данные из исправной информационной базы:

#Linux
COPY config FROM '/var/lib/postgresql/config_OK.txt';#Windows
COPY config FROM 'D:/backup/config_OK.txt';

Для выхода из терминала PostgreSQL введите:

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

В некоторых случаях оказывается повреждена не основная конфигурация информационной базы, а конфигурация, открытая на редактирование в Конфигураторе. Внешне это проявляется как невозможность загрузить информационную базу в этом режиме. Для исправления этой ошибки достаточно очистить таблицу configsave:

DELETE FROM configsave;

Как видим, устранение ошибки формата потока средствами СУБД PostgreSQL достаточно несложно, однако требует некоторых навыков работы с данной СУБД. Но если вы будете внимательно и вдумчиво следовать нашей инструкции, то проблем у вас возникнуть не должно.

Прежде чем кто-либо сможет получить доступ к базе данных, вы должны запустить сервер базы данных. Программа сервера базы данных называется postgres .

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

Самый простой способ запустить сервер вручную — это просто вызвать postgres напрямую, указав расположение каталога данных с помощью опции -D , например:

$ postgres -D /usr/local/pgsql/data

что оставит сервер работающим на переднем плане. Это необходимо сделать, войдя в учетную запись пользователя PostgreSQL. Без -D сервер попытается использовать каталог данных, названный переменной среды PGDATA . Если эта переменная также не указана, произойдет сбой.

Обычно лучше запускать postgres в фоновом режиме. Для этого используйте обычный синтаксис оболочки Unix:

$ postgres -D /usr/local/pgsql/data >logfile 2>&1 &

Важно где-нибудь хранить выходные данные сервера и stdout, как показано выше. Это поможет в целях аудита и диагностики проблем. (См. Раздел 25.3 для более подробного обсуждения обработки файлов журнала.)

Программа postgres также принимает ряд других параметров командной строки. Для получения дополнительной информации см. справочную страницу postgres и главу 20 ниже.

Этот синтаксис оболочки может быстро стать утомительным. Поэтому программа-оболочка pg_ctl предназначена для упрощения некоторых задач. Например:

pg_ctl start -l logfile

запустит сервер в фоновом режиме и поместит результат в указанный файл журнала. Параметр -D здесь имеет то же значение, что и для postgres . pg_ctl также может останавливать сервер.

Обычно вам нужно запускать сервер базы данных при загрузке компьютера. Сценарии автозапуска зависят от операционной системы. Есть несколько примеров сценариев, распространяемых с PostgreSQL в каталоге contrib/start-scripts . Для его установки потребуются права root.

В разных системах существуют разные соглашения о запуске демонов во время загрузки. Во многих системах есть файл /etc/rc.local или /etc/rc.d/rc.local . Другие используют каталоги init.d или rc.d . Что бы вы ни делали, сервер должен запускаться под учетной записью пользователя PostgreSQL, а не под root или каким-либо другим пользователем. Поэтому вам, вероятно, следует формировать свои команды, используя su postgres -c '...' . Например:

su postgres -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog'

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

Для FreeBSD посмотрите файл contrib/start-scripts/freebsd в исходном дистрибутиве PostgreSQL.

В OpenBSD добавьте следующие строки в файл /etc/rc.local :

if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then
    su -l postgres -c '/usr/local/pgsql/bin/pg_ctl start -s -l /var/postgresql/log -D /usr/local/pgsql/data'
    echo -n ' postgresql'
fi

В системах Linux либо добавьте
```
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
```
в /etc/rc.d/rc.local или /etc/rc.local или просмотрите файл contrib/start-scripts/linux в дистрибутиве исходного кода PostgreSQL.

При использовании systemd вы можете использовать следующий файл служебной единицы (например, в /etc/systemd/system/postgresql.service ):
```
[Unit]
Description=PostgreSQL database server
Documentation=man:postgres(1)

[Service]
Type=notify
User=postgres
ExecStart=/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
ExecReload=/bin/kill -HUP $MAINPID
KillMode=mixed
KillSignal=SIGINT
TimeoutSec=infinity

[Install]
WantedBy=multi-user.target
```
Использование Type=notify требует, чтобы двоичный файл сервера был собран с помощью configure --with-systemd .

Внимательно рассмотрите настройку тайм-аута. На момент написания этой статьи systemd имеет тайм-аут по умолчанию 90 секунд и уничтожит процесс, который не сообщит о готовности в течение этого времени. Но серверу PostgreSQL, которому, возможно, придется выполнять аварийное восстановление при запуске, подготовка к работе может занять гораздо больше времени. Предлагаемое значение infinity отключает логику тайм-аута.
На NetBSD используйте либо скрипты запуска FreeBSD,либо Linux,в зависимости от предпочтений.
В Solaris создайте файл с именем /etc/init.d/postgresql , содержащий следующую строку:
```
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
```
Затем создайте на него символическую ссылку в /etc/rc3.d как S99postgresql .

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

19.3.1.Сбои при запуске сервера

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

LOG:  could not bind IPv4 address "127.0.0.1": Address already in use
HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
FATAL:  could not create any TCP/IP sockets

Обычно это означает именно то, что он предлагает: вы пытались запустить другой сервер на том же порту, где он уже работает. Однако, если сообщение об ошибке ядра не « Address already in use или какой-то его вариант, может быть другая проблема. Например, при попытке запустить сервер на зарезервированном номере порта может появиться что-то вроде:

$ postgres -p 666
LOG:  could not bind IPv4 address "127.0.0.1": Permission denied
HINT:  Is another postmaster already running on port 666? If not, wait a few seconds and retry.
FATAL:  could not create any TCP/IP sockets

Сообщение вроде:

FATAL:  could not create shared memory segment: Invalid argument
DETAIL:  Failed system call was shmget(key=5440001, size=4011376640, 03600).

вероятно, это означает, что ограничение вашего ядра на размер разделяемой памяти меньше, чем рабочая область, которую PostgreSQL пытается создать (4011376640 байт в этом примере). Это может произойти, только если вы установили shared_memory_type на sysv . В этом случае вы можете попробовать запустить сервер с меньшим, чем обычно, количеством буферов ( shared_buffers ) или перенастроить ядро, чтобы увеличить разрешенный размер разделяемой памяти. Вы также можете увидеть это сообщение при попытке запустить несколько серверов на одном компьютере, если их общее запрошенное пространство превышает ограничение ядра.

Ошибка типа..:

FATAL:  could not create semaphores: No space left on device
DETAIL:  Failed system call was semget(5440126, 17, 03600).

вовсе не означает , что вы бежите из дискового пространства. Это означает, что ограничение вашего ядра на количество семафоров System V меньше, чем количество, которое PostgreSQL хочет создать. Как и выше, вы можете обойти проблему, запустив сервер с уменьшенным количеством разрешенных соединений ( max_connections ), но в конечном итоге вы захотите увеличить лимит ядра.

Подробная информация о настройке средств IPC System V приведена в Разделе 19.4.1 .

19.3.2.Проблемы с подключением клиента

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

psql: error: connection to server at "server.joe.com" (123.123.123.123), port 5432 failed: Connection refused
        Is the server running on that host and accepting TCP/IP connections?

Это общий сбой «Я не смог найти сервер,с которым можно поговорить».Он выглядит как показано выше при попытке соединения по протоколу TCP/IP.Распространенная ошибка-забыть настроить сервер на разрешение TCP/IP-соединений.

В качестве альтернативы,вы можете получить это при попытке связи сокета Unix-домена с локальным сервером:

psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file or directory
        Is the server running locally and accepting connections on that socket?

Если сервер действительно работает, убедитесь, что представление клиента о пути к сокету (здесь /tmp ) согласуется с настройкой сервера unix_socket_directories .

В сообщении об ошибке подключения всегда отображается адрес сервера или путь к сокету, что полезно для проверки того, что клиент пытается подключиться к нужному месту. Если на самом деле сервер там не прослушивает, сообщение об ошибке ядра обычно будет либо В Connection refused либо No such file or directory , как показано. (Важно понимать, что Connection refused в соединении в этом контексте не означает, что сервер получил ваш запрос на соединение и отклонил его. В этом случае будет выдано другое сообщение, как показано в Разделе 21.15 .) Другие сообщения об ошибках, такие как Connection timed out может указывать на более серьезные проблемы, такие как отсутствие подключения к сети или брандмауэр, блокирующий подключение.

PostgreSQL

15.0

F.40.5.3.Разрешения DDL: SELinux определяет несколько разрешений для управления общими операциями для каждого типа объекта; такие как создание, изменение, удаление и перемаркировка безопасности Создание новых
19.5.Выключение сервера: Существует несколько способов отключения сервера баз данных.
69.2.Встроенные классы операторов: В основной дистрибутив PostgreSQL включены классы операторов SP-GiST,представленные в таблице 69.1.
69.5. Examples: Исходный дистрибутив PostgreSQL включает несколько примеров классов индексных операторов для SP-GiST,описанных в таблице 69.1.

Содержание

В данном разделе собраны ошибки, связанные с обновлением PostgreSQL с версии 9.5 до 10

Версия АРМ ЭРС — 3.0.30

Обязательно делайте резервную копию базы данных!

PostgreSQL 10 при обновлении ставится поверх версии 9.5

Убедитесь, что у вас открыт порт 5433 в брандмауэре

Вернуться в основную статью

В соответствии с рекомендациями ФСТЭК с 11.10.2022 будет выложена новая версия АРМ ЛПУ (ЭРС) с PostgreSQL — 10.22. При переходе на версию АРМ ЛПУ (ЭРС) 3.0.30 необходимо выполнить следующие шаги:

1. Сделать резервную копию данных (Администрирование → Резервное копирование базы данных).

2. При установке новой версии АРМ ЛПУ ОБЯЗАТЕЛЬНО выбрать пункт «Установить» на вкладке «Параметры подключения к базе данных». В строке порт соединения ОБЯЗАТЕЛЬНО указать новый номер порта (по умолчанию — 5433), отличный от номера для PostgreSQL 9.5 (по умолчанию — 5432).

3. После запуска АРМ ЛПУ в настройках соединения с базой данных (Администрирование → Настройки соединения с базой данных) ОБЯЗАТЕЛЬНО заменить номер порта на новый.

4. Восстановить данные из резервной копии (Администрирование → Восстановление базы данных).

Примечание:
Если вы используете подключение к базе данных, установленной на удаленный сервер, то сначала нужно установить новую версию ЛПУ на этот сервер с учетом условий выше.

Ошибка: Возникла ошибка при попытке загрузки данных из базы данных. Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment].

Причина:

Нет подключения к базе АРМ ЭРС

Решение:

1. Предварительно сделав резервную копию БД — удалить PostgreSQL10.

2. Очистить папку C:PostgreSQL10

3. Открываем установочный .exe файл АРМ ЭРС в 7zfm.

4. Вытаскиваем оттуда postgresql-10.22-1-windows.exe.

5. Запускаем postgresql-10.22-1-windows.exe, устанавливаем в папку C:postgresql10, пароль Manager1 порт 5433

6. Запускаем установку АРМ ЛПУ

Ошибка: Error deleting service при попытке удаления postgreSQL

Решение:

Win+R — cmd

в командной строке написать:

для 32-разрядных систем:

sc delete postgresql-10

или для 64-разрядных систем:

sc delete postgresql-x64-10

Принудительно изменить порт используемый программой АРМ ЭРС

Если нет возможности войти в программу и поменять порт (например из-за недоступности БД):

Переходим в C:FssArmErsconfiguration.settings

Открываем файл: ru.ibs.fss.eln.prefs

Редактируем строку

dburl=jdbc:postgresql://localhost:5433/fss

Где 5433 — порт

Доступ в PGAdmin

Для доступа в админку СУБД нужно перейти в: C:postgresqlbin

Запустить файл: pgAdmin3.exe

Правой кнопкой мыши на БД — Подключиться

Логин: postgres
Пароль: Manager1

Резервное копирование базы данных

Для резервного копирования БД необходимо в c:PostgreSQL создать bat-файл со следующим содержимым:

REM СОЗДАНИЕ РЕЗЕРВНОЙ КОПИИ БАЗЫ ДАННЫХ POSTGRESQL
CLS
ECHO OFF
CHCP 1251
REM Установка переменных окружения
SET PGBIN=c:PostgreSQLbin
SET PGDATABASE=fss
SET PGHOST=localhost
SET PGPORT=5433
SET PGUSER=postgres
SET PGPASSWORD=Manager1
REM Смена диска и переход в папку из которой запущен bat-файл
%~d0
CD %~dp0
REM Формирование имени файла резервной копии и файла-отчета
SET DATETIME=%DATE:~6,4%-%DATE:~3,2%-%DATE:~0,2% %TIME:~0,2%-%TIME:~3,2%-%TIME:~6,2%
SET DUMPFILE=%PGDATABASE%.backup
SET LOGFILE=%PGDATABASE%.log
SET DUMPPATH="C:backup_db_fss%DUMPFILE%"
SET LOGPATH="C:backup_db_fss%LOGFILE%"
REM Создание резервной копии
IF NOT EXIST Backup MD Backup
CALL "%PGBIN%pg_dump.exe" --format=custom --verbose --file=%DUMPPATH% 2>%LOGPATH%
REM Анализ кода завершения
IF NOT %ERRORLEVEL%==0 GOTO Error
GOTO Successfull
REM В случае ошибки удаляется поврежденная резервная копия и делается соответствующая запись в журнале
:Error
DEL %DUMPPATH%
MSG * "Ошибка при создании резервной копии базы данных. Смотрите backup.log."
ECHO %DATETIME% Ошибки при создании резервной копии базы данных %DUMPFILE%. Смотрите отчет %LOGFILE%. >> backup.log
GOTO End
REM В случае удачного резервного копирования просто делается запись в журнал
:Successfull
ECHO %DATETIME% Успешное создание резервной копии %DUMPFILE% >> backup.log
GOTO End
:End

в строках:

SET DUMPPATH="C:backup_db_fss%DUMPFILE%"

SET LOGPATH="C:backup_db_fss%LOGFILE%"

необходимо выставить свой путь для сохранения бэкапа БД и логов (переменные %DUMPFILE% и %LOGFILE% не трогать)

После этого необходимо добавить данный bat-файл в планировщик заданий для выполнения задачи резервного копирования по расписанию.

Как восстановить базу данных из Бекапа?

Скопируем резервную копию базы fss.backup, которую мы создали скриптом выше в папку c:postgresqlbin

Открываем командную строку (cmd.exe):

c:postgresqlbin>pg_restore.exe -p 5433 -U fss -d fss < fss.backup

Ошибка 1С «Сервер баз данных не обнаружен»

При работе с 1С в клиент-серверном варианте могут возникать ошибки, которые напрямую не связаны с 1С:Предприятием, а связаны непосредственно с сервером управления баз данных.

Одна из распространенных ошибок — «Сервер баз данных не обнаружен…».

Продолжение данного сообщения может быть различным:

1. Could not translate host name «NAME» to address: Temporary failure in name resolution

2. ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident)

3. ВАЖНО: в pg_hba.conf нет записи для компьютера «», пользователя «usr1cv8», базы «template»

4. Is the server running on host and accepting TCP/IP connections on port 5432?

5. «Породить новый процесс для соединения не удалось: Ресурс временно недоступен» или «ВАЖНО: извините, уже слишком много клиентов.»

6. FATAL: database «base» does not exist

Далее рассмотрим подробнее каждую ошибку.

Could not translate host name «NAME» to address: Temporary failure in name resolution

Пример полного текста ошибки:

Сервер баз данных не обнаружен

could not translate host name «NAME» to address: Temporary failure in name resolution

Описание:

Ошибка может возникать как при создании базы, так и при запуске информационной базы.

Решение:

Настроим DNS-адресацию или пропишем адреса в файл hosts. Обратите внимание, что в данном случае проблема в том, что на сервере 1С нет информации о доменном имени сервера СУБД PostgreSQL. Подробнее о DNS — Настройка DNS-адресации для 1С сервера.

ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident)

Пример полного текста ошибки:

Сервер баз данных не обнаружен

ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident)

Описание: Ошибка возникает при создании базы.

Решение:

Настроим проверку подлинности.

1. Сконфигурируем доступ к серверу PostgreSQL в файле: pg_hba.conf:

vim /var/lib/pgsql/11/data/pg_hba.conf

Файл должен содержать только следующие строки (содержащие ip серверов 1С) (остальные удалим или пометим как комментарий):

# TYPE DATABASE USER ADDRESS METHOD

local all all trust

host all all «Указать ip-адрес сервера 1С» md5

Строк должно быть, соответственно, несколько, если серверов 1С несколько в кластере.

Последняя колонка указывает на метод авторизации.

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

# TYPE DATABASE USER ADDRESS METHOD

local all all trust

host all all 0.0.0.0/0 trust

А после удачного старта сервера СУБД разбираться с настройками доступа.

ВАЖНО: в pg_hba.conf нет записи для компьютера «», пользователя «usr1cv8», базы «template»

Пример полного текста ошибки:

Сервер баз данных не обнаружен ВАЖНО: в pg_hba.conf нет записи для компьютера «», пользователя «usr1cv8», базы «template».

Описание ошибки:

Ошибка связана с отсутствием прописанного доступа к базе данных в файле pg_hba.conf

Решение:

Добавим запись в файл pg_hba.conf.

Приведем пример содержания файла, который открывает доступ:

# TYPE DATABASE USER ADDRESS METHOD

local all all trust

host all all «Указать ip-адрес сервера 1С» md5

Строк должно быть, соответственно, несколько, если серверов 1С несколько в кластере.

Is the server running on host and accepting TCP/IP connections on port 5432?

Пример полного текста ошибки:

Сервер баз данных не обнаружен could not connect to server: No rout to host Is the server running on host and accepting TCP/IP connections on port 5432?

Описание:

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

Решение:

В данном случае необходимо понимать, что рабочего процесса:

Либо нет;

Либо клиент(в нашем случае сервер 1С) его не «видит» по ряду причин:

— Отсутствие доступа;

— Обращение по другому адресу.

1. Первоначально, конечно, проверим, есть ли на сервере СУБД PostgreSQL в запущенных процессах процесс postmaster/postgres (в зависимости от версии PostgreSQL) на порту 5432.

netstat –tlnp | grep 5432

Или

1.1. Если по результатам проверки видим, что не запущен процесс, то необходимо его запустить.

service postgresql—11 start

1.2. Если по результатам проверки видим, что процесс запущен, но слушает только «себя» 127.0.0.1.

То выполним ряд настроек.

Отредактируем конфигурационный файл

vim /var/lib/pgsql/11/data/postgresql.conf

Укажем там настройку:

1.3. Если видим, что процесс запущен

То переходим к следующем пункту.

2. Проверим доступность процесса по порту, который он «слушает».

С сервера 1С выполним команду(в нашем случае имя сервера СУБД «1s-on-pg-1»):

Если доступ отсутствует – то мы увидим нечто подобное:

Подключение к 333.33.33.xx…Не удалось открыть подключение к этому узлу, на порт 5432: Сбой подключения

К причинам отсутствия доступа по данному порту можно отнести:

Блокировка брадмауэром или другими подобными программами;
Отсутствие доступа на уровне сети.

2.1. Проверим статус файерволла.

systemctl status firewalld

Если файерволл работает и блокирует порт 5432, то.

Отключим firewall:

и отключим автозапуск.

systemctl disable firewalld

Результат должен быть следующим:

systemctl status firewalld

или

настроим, открыв порт 5432.

iptables —t filter —I INPUT —p tcp —dport 5432 —j ACCEPT

service iptables save

«Породить новый процесс для соединения не удалось: Ресурс временно недоступен» или «ВАЖНО: извините, уже слишком много клиентов»

Пример полного текста ошибки:

Сервер баз данных не обнаружен породить новый процесс для соединения не удалось: Ресурс временно недоступен

или

Сервер баз данных не обнаружен ВАЖНО: извините, уже слишком много клиентов

Описание:

В процессе работы выдается ошибка

Решение:

Изменим настройку в файле postgresql.conf

Данное число, должно быть примерно в 1.5 раза больше максимального количества пользователей.

Установим ее:

1. Перейдем в терминал psql.

1. Через psql установим следующие параметры командой ALTER SYSTEM SET:

ALTER SYSTEM SET max_connections=500;

FATAL: database «base» does not exist

Пример полного текста ошибки:

Сервер баз данных не обнаружен

FATAL: database «base» does not exist

Описание:

При запуске базы данных выдается ошибка, которая говорит о том, что данная база не существует.

Решение:

Проверим наименование базы данных и информационной базы. Сделать это можно в консоли администрирования 1С в свойствах базы.

Учтём, что Linux чувствителен к регистру(Base/base/BASE – для него это разные имена баз).

Источник

Время на прочтение
9 мин

Количество просмотров 34K

Хочу поделиться с вами моим первым успешным опытом восстановления полной работоспособности базы данных Postgres. С СУБД Postgres я познакомился пол года назад, до этого опыта администрирования баз данных у меня не было совсем.

Я работаю полу-DevOps инженером в крупной IT-компании. Наша компания занимается разработкой программного обеспечения для высоконагруженных сервисов, я же отвечаю за работоспособность, сопровождение и деплой. Передо мной поставили стандартную задачу: обновить приложение на одном сервере. Приложение написано на Django, во время обновления выполняются миграции (изменение структуры базы данных), и перед этим процессом мы снимаем полный дамп базы данных через стандартную программу pg_dump на всякий случай.

Во время снятия дампа возникла непредвиденная ошибка (версия Postgres – 9.5):

pg_dump: Oumping the contents of table “ws_log_smevlog” failed: PQgetResult() failed.
pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989
pg_dump: The command was: COPY public.ws_log_smevlog [...]
pg_dunp: [parallel archtver] a worker process dled unexpectedly

Ошибка «invalid page in block» говорит о проблемах на уровне файловой системы, что очень нехорошо. На различных форумах предлагали сделать FULL VACUUM с опцией zero_damaged_pages для решения данной проблемы. Что же, попрробеум…

Подготовка к восстановлению

ВНИМАНИЕ! Обязательно сделайте резервную копию Postgres перед любой попыткой восстановить базу данных. Если у вас виртуальная машина, остановите базу данных и сделайте снепшот. Если нет возможности сделать снепшот, остановите базу и скопируйте содержимое каталога Postgres (включая wal-файлы) в надёжное место. Главное в нашем деле – не сделать хуже. Прочтите это.

Поскольку в целом база у меня работала, я ограничился обычным дампом базы данных, но исключил таблицу с повреждёнными данными (опция -T, —exclude-table=TABLE в pg_dump).

Сервер был физическим, снять снепшот было невозможно. Бекап снят, двигаемся дальше.

Проверка файловой системы

Перед попыткой восстановления базы данных необходимо убедиться, что у нас всё в порядке с самой файловой системой. И в случае ошибок исправить их, поскольку в противном случае можно сделать только хуже.

В моём случае файловая система с базой данных была примонтирована в «/srv» и тип был ext4.

Останавливаем базу данных: systemctl stop postgresql@9.5-main.service и проверяем, что файловая система никем не используется и её можно отмонтировать с помощью команды lsof:
lsof +D /srv

Мне пришлось ещё остановить базу данных redis, так как она тоже исползовала «/srv». Далее я отмонтировал /srv (umount).

Проверка файловой системы была выполнена с помощью утилиты e2fsck с ключиком -f (Force checking even if filesystem is marked clean):

Далее с помощью утилиты dumpe2fs (sudo dumpe2fs /dev/mapper/gu2—sys-srv | grep checked) можно убедиться, что проверка действительно была произведена:

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

Если у вас сервер физический, то обязательно проверьте состояние дисков (через smartctl -a /dev/XXX) либо RAID-контроллера, чтобы убедиться, что проблема не на аппаратном уровне. В моём случае RAID оказался «железный», поэтому я попросил местного админа проверить состояние RAID (сервер был в нескольких сотнях километров от меня). Он сказал, что ошибок нет, а это значит, что мы точно можем начать восстановление.

Попытка 1: zero_damaged_pages

Подключаемся к базе через psql аккаунтом, обладающим правами суперпользователя. Нам нужен именно суперпользователь, т.к. опцию zero_damaged_pages может менять только он. В моём случае это postgres:

psql -h 127.0.0.1 -U postgres -s [database_name]

Опция zero_damaged_pages нужна для того, чтобы проигнорировать ошибки чтения (с сайта postgrespro):

При выявлении повреждённого заголовка страницы Postgres Pro обычно сообщает об ошибке и прерывает текущую транзакцию. Если параметр zero_damaged_pages включён, вместо этого система выдаёт предупреждение, обнуляет повреждённую страницу в памяти и продолжает обработку. Это поведение разрушает данные, а именно все строки в повреждённой странице.

Включаем опцию и пробуем делать full vacuum таблицы:

VACUUM FULL VERBOSE

К сожалению, неудача.

Мы столкнулись с аналогичной ошибкой:

INFO: vacuuming "“public.ws_log_smevlog”
WARNING: invalid page in block 4123007 of relation base/16400/21396989; zeroing out page
ERROR: unexpected chunk number 573 (expected 565) for toast value 21648541 in pg_toast_106070

pg_toast – механизм хранения «длинных данных» в Postgres, если они не помещаются в одну страницу (по умолчанию 8кб).

Попытка 2: reindex

Первый совет из гугла не помог. После нескольких минут поиска я нашёл второй совет – сделать reindex повреждённой таблицы. Этот совет я встречал во многих местах, но он не внушал доверия. Сделаем reindex:

reindex table ws_log_smevlog

reindex завершился без проблем.

Однако это не помогло, VACUUM FULL аварийно завершался с аналогичной ошибкой. Поскольку я привык к неудачам, я стал искать советов в интернете дальше и наткнулся на довольно интересную статью.

Попытка 3: SELECT, LIMIT, OFFSET

В статье выше предлагали посмотреть таблицу построчно и удалить проблемные данные. Для начала необходимо было просмотреть все строки:

for ((i=0; i<"Number_of_rows_in_nodes"; i++ )); do psql -U "Username" "Database Name" -c "SELECT * FROM nodes LIMIT 1 offset $i" >/dev/null || echo $i; done

В моём случае таблица содержала 1 628 991 строк! По-хорошему необходимо было позаботиться о партициирвоании данных, но это тема для отдельного обсуждения. Была суббота, я запустил вот эту команду в tmux и пошёл спать:

for ((i=0; i<1628991; i++ )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog LIMIT 1 offset $i" >/dev/null || echo $i; done

К утру я решил проверить, как обстоят дела. К моему удивлению, я обнаружил, что за 20 часов было просканировано только 2% данных! Ждать 50 дней я не хотел. Очередной полный провал.

Но я не стал сдаваться. Мне стало интересно, почему же сканирование шло так долго. Из документации (опять на postgrespro) я узнал:

OFFSET указывает пропустить указанное число строк, прежде чем начать выдавать строки.
Если указано и OFFSET, и LIMIT, сначала система пропускает OFFSET строк, а затем начинает подсчитывать строки для ограничения LIMIT.

Применяя LIMIT, важно использовать также предложение ORDER BY, чтобы строки результата выдавались в определённом порядке. Иначе будут возвращаться непредсказуемые подмножества строк.

Очевидно, что вышенаписанная команда была ошибочной: во-первых, не было order by, результат мог получиться ошибочным. Во-вторых, Postgres сначала должен был просканировать и пропустить OFFSET-строк, и с возрастанием OFFSET производительность снижалась бы ещё сильнее.

Попытка 4: снять дамп в текстовом виде

Далее мне в голову пришла, казалось бы, гениальная идея: снять дамп в текстовом виде и проанализировать последнюю записанную строку.

Но для начала, ознакомимся со структурой таблицы ws_log_smevlog:

В нашем случае у нас есть столбец «id», который содержал уникальный идентификатор (счётчик) строки. План был такой:

Начинаем снимать дамп в текстовом виде (в виде sql-команд)
В определённый момент времени снятия дампа бы прервалось из-за ошибки, но тектовый файл всё равно сохранился бы на диске
Смотрим конец текстового файла, тем самым мы находим идентификатор (id) последней строки, которая снялась успешно

Я начал снимать дамп в текстовом виде:

pg_dump -U my_user -d my_database -F p -t ws_log_smevlog -f ./my_dump.dump

Снятия дампа, как и ожидалось, прервался с той же самой ошибкой:

pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989

Далее через tail я просмотрел конец дампа (tail -5 ./my_dump.dump) обнаружил, что дамп прервался на строке с id 186 525. «Значит, проблема в строке с id 186 526, она битая, её и надо удалить!» – подумал я. Но, сделав запрос в базу данных:
«select * from ws_log_smevlog where id=186529» обнаружилось, что с этой строкой всё нормально… Строки с индексами 186 530 — 186 540 тоже работали без проблем. Очередная «гениальная идея» провалилась. Позже я понял, почему так произошло: при удаленииизменении данных из таблицы они не удаляются физически, а помечаются как «мёртвые кортежи», далее приходит autovacuum и помечает эти строки удалёнными и разрешает использовать эти строки повторно. Для понимания, если данные в таблице меняются и включён autovacuum, то они не хранятся последовательно.

Попытка 5: SELECT, FROM, WHERE id=

Неудачи делают нас сильнее. Не стоит никогда сдаваться, нужно идти до конца и верить в себя и свои возможности. Поэтому я решил попробовать ешё один вариант: просто просмотреть все записи в базе данных по одному. Зная структуру моей таблицы (см. выше), у нас есть поле id, которое является уникальным (первичным ключом). В таблице у нас 1 628 991 строк и id идут по порядку, а это значит, что мы можем просто перербрать их по одному:

for ((i=1; i<1628991; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

Если кто не понимает, команда работает следующим образом: просматривает построчно таблицу и отправляет stdout в /dev/null, но если команда SELECT проваливается, то выводится текст ошибки (stderr отправляется в консоль) и выводится строка, содержащая ошибку (благодаря ||, которая означает, что у select возникли проблемы (код возврата команды не 0)).

Мне повезло, у меня были созданы индексы по полю id:

А это значит, что нахождение строки с нужным id не должен занимать много времени. В теории должно сработать. Что же, запускаем команду в tmux и идём спать.

К утру я обнаружил, что просмотрено около 90 000 записей, что составляет чуть более 5%. Отличный результат, если сравнивать с предыдущим способом (2%)! Но ждать 20 дней не хотелось…

Попытка 6: SELECT, FROM, WHERE id >= and id <

У заказчика под БД был выделен отличный сервер: двухпроцессорный Intel Xeon E5-2697 v2, в нашем расположении было целых 48 потоков! Нагрузка на сервере была средняя, мы без особых проблем могли забрать около 20-ти потоков. Оперативной памяти тоже было достаточно: аж 384 гигабайт!

Поэтому команду нужно было распараллелить:

for ((i=1; i<1628991; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

Тут можно было написать красивый и элегантный скрипт, но я выбрал наиболее быстрый способ распараллеливания: разбить диапазон 0-1628991 вручную на интервалы по 100 000 записей и запустить отдельно 16 команд вида:

for ((i=N; i<M; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

Но это не всё. По идее, подключение к базе данных тоже отнимает какое-то время и системные ресурсы. Подключать 1 628 991 было не очень разумно, согласитесь. Поэтому давайте при одном подключении извлекать 1000 строк вместо одной. В итоге команда преобразилоась в это:

for ((i=N; i<M; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done

Открываем 16 окон в сессии tmux и запускаем команды:

1) for ((i=0; i<100000; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
2) for ((i=100000; i<200000; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
…
15) for ((i=1400000; i<1500000; i=$((i+1000)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
16) for ((i=1500000; i<1628991; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done

Через день я получил первые результаты! А именно (значения XXX и ZZZ уже не сохранились):

ERROR:  missing chunk number 0 for toast value 37837571 in pg_toast_106070
829000
ERROR:  missing chunk number 0 for toast value XXX in pg_toast_106070
829000
ERROR:  missing chunk number 0 for toast value ZZZ in pg_toast_106070
146000

Это значит, что у нас три строки содержат ошибку. id первой и второй проблемной записи находились между 829 000 и 830 000, id третьей – между 146 000 и 147 000. Далее нам предстояло просто найти точное значение id проблемных записей. Для этого просматриваем наш диапазон с проблемными записями с шагом 1 и идентифицируем id:

for ((i=829000; i<830000; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done
829417
ERROR:  unexpected chunk number 2 (expected 0) for toast value 37837843 in pg_toast_106070
829449
for ((i=146000; i<147000; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done
829417
ERROR:  unexpected chunk number ZZZ (expected 0) for toast value XXX in pg_toast_106070
146911

Счастливый финал

Мы нашли проблемные строки. Заходим в базу через psql и пробуем их удалить:

my_database=# delete from ws_log_smevlog where id=829417;
DELETE 1
my_database=# delete from ws_log_smevlog where id=829449;
DELETE 1
my_database=# delete from ws_log_smevlog where id=146911;
DELETE 1

К моему удивлению, записи удалились без каких-либо проблем даже без опции zero_damaged_pages.

Затем я подключился к базе, сделал VACUUM FULL (думаю делать было необязательно), и, наконец, успешно снял бекап с помощью pg_dump. Дамп снялся без каких либо ошибок! Проблему удалось решить таким вот тупейшим способом. Радости не было предела, после стольких неудач удалось найти решение!

Благодарности и заключение

Вот такой получился мой первый опыт восстановления реальной базы данных Postgres. Этот опыт я запомню надолго.

Ну и напоследок, хотел бы сказать спасибо компании PostgresPro за переведённую документацию на русский язык и за полностью бесплатные online-курсы, которые очень сильно помогли во время анализа проблемы.

Источник

kukusik@kukusik-TM1613:~$ sudo -u postgres psql
psql (11.5 (Ubuntu 11.5-3.pgdg18.04+1))
Введите «help», чтобы получить справку.

postgres=# select * from pg_database;
postgres=# create database secure;
CREATE DATABASE
postgres=# CREATE USER test_user WITH password ‘qwerty’;
CREATE ROLE
postgres=# GRANT ALL ON DATABASE secure TO test_user;
GRANT
postgres-# q

kukusik@kukusik-TM1613:~$ psql -h localhost secure test_user
Пароль пользователя test_user:
psql: FATAL: database «secure» does not exist

хотя при наборе select * from pg_database;
все врроде как норм

Источник

Unable to connect to server: could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host «localhost» (::1) and accepting TCP/IP connections on port 5432? could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host «localhost» (127.0.0.1) and accepting TCP/IP connections on port 5432?

asked Nov 10, 2016 at 16:23

On windows, Just go to the ‘Services’. Start/Restart the postgresql-X64 service. It worked for me as my service was in stopped state somehow.

answered Feb 23, 2020 at 7:06

gagan chhabragagan chhabra

1,3551 gold badge8 silver badges9 bronze badges

There are two items to configure if your server isn’t on localhost:

find your postgresql.conf and add your server’s public IP address to the end of the setting listen_addresses (separate multiple entries by commas); uncomment the line if it is commented out (e.g. with ‘#’)
add a line to pg_hba.conf containing your client’s IP address — you may copy the line containing 127.0.0.1 and change only the IP address

On Ubuntu, these files are in /etc/postgresql/<version>/main/.

answered Mar 14, 2017 at 1:12

In my case I couldnt’ open the pgAdmin4, for some reason. I use Postgresql 10 and pgAdmin4

The port in the postgresql.conf was not the same as in the pgAdmin4 —> postgreSQL 10 —> properties —> Connection —> port.

I fixed it and it worked. Check if those 2 are in line.

answered Sep 12, 2020 at 13:55

First press win key+R
Search for services.msc
A window will open in that find postgresql-x64-13 and open that, in that tab click start option
For me its works perfectly.

answered May 31, 2021 at 5:03

VADHANVADHAN

2313 silver badges2 bronze badges

Go to PgAdmin
Right click on PostgreSQL
3.Choose properties
At the top, select connection
Try changing the port from 5433 to 5432 or vice versa.

And re-enter.

answered May 15, 2021 at 17:27

On windows, Just go to the ‘Services’. Start/Restart the postgresql-X64 service. It worked for me as my service was in stopped state somehow.

worked for me

answered Sep 10, 2020 at 18:00

devyan91devyan91

891 silver badge6 bronze badges

answered Aug 7, 2020 at 21:49

Tim UzlovTim Uzlov

1812 silver badges6 bronze badges

This happened because I installed two versions of Postgres (v12 and v13). Psql 12 was installed later so got the port 5433. I needed to use Postgres 12. To fix this particular case:

Go to Program Files/Postgres/<required_version>/data

Open the postgresql.conf file

Search for Port and change the port number to 5432.
Open Windows Services (Press Cmd + R then type services.msc)
Stop the service for the version you don’t want (You can stop it permanentally from the Right Click > Properties menu.)
Start the service for the version you want.

answered Aug 7, 2021 at 14:30

Nitin NainNitin Nain

5,0621 gold badge36 silver badges51 bronze badges

Summary: There are 2 Solutions:

Open Services and make sure that postgresql-x64-14 is running.
Go to C:Program FilesPostgreSQL14data and open postgresql.conf with notepad, find and change port to e.g 5432 and after that open Services and restart postgresql-x64-14.

answered Apr 11, 2022 at 16:06

MaceMace

1311 silver badge6 bronze badges

To fix you can try change localhost to ‘‘ as in «listen_addresses = ‘‘».

As seen as "listen_addresses = 'localhost'" under «Connection Settings» in the postgresql.conf file.

Also to access your postgresql.conf file, go to:

On Windows, the file is in /Program Files/PostgreSQL/<version>/share/.
On Ubuntu, these files are in /etc/postgresql/<version>/main/.

P.S: Changing the defaults ‘localhost’; to ‘*’ will let your server listen to any public database address either «localhost, 127.0.0.1 etc.

I know you might have fix this, just for others that might run into the same issue in the future. Hope it was helpful

answered Jul 31, 2019 at 14:41

When I run psql, it gave me the same error, and it was because I changed the port while setting Postgres in the installation process.

I had to change back to the default port 5432 in PostgreSQL.conf (which can be found in the data directory) i.e

C:Program FilesPostgreSQL14data>

The problem is no more!

answered Jul 19, 2022 at 15:19

goto service and start postgresql-x64-10 service

steps

run -> services.msc -> find postgresql-x64-10 -> start the service
services image

answered Mar 12, 2021 at 14:33

This is a note for a normal user. If using an official installer, it should have a built-in service,

Win+R and type services.msc
Search Postgres service based on the version installed, e.g., «postgresql-x64-13 - PostgreSQL Server 13«
Click stop, start, or restart the service option
If you don’t see start/stop or if these buttons are disabled, then double-click on the PostgreSQL and change startup type to automatic and click on start. This will start the PostgreSQL every time automatically whenever you start your system.

answered Jul 6, 2021 at 2:54

Manoj SwamiManoj Swami

872 silver badges12 bronze badges

I cancelled the installation and then tried again, but with a plain-text password this time, and it worked. It turned out that the special characters in my password were the problem.

ouflak

2,44810 gold badges44 silver badges49 bronze badges

answered Oct 1, 2021 at 14:48

I got this error message when I moved my database to another computer.

I also got some error messages when starting the server first with

pg_ctl -D /wherever/your/database/is start

which were

pg_ctl: another server might be running; trying to start server anyway
server starting

DETAIL: File «/wherever/your/database/is/PG_VERSION» does not contain valid data.

HINT: You might need to initdb.

In my case rather than running initdb this command actually fixed the issue

pg_ctl -D /wherever/your/database/is restart

answered May 10, 2018 at 13:42

uosjeaduosjead

4266 silver badges5 bronze badges

You might have changed the permissions of the ‘PostgreSQL 12’ in ‘services.msc’. Or maybe it is not started and you are trying to start the server when Postgre 12 is not running.

Try these:

Try to start the ‘PostgreSQL 12’ in ‘services.msc’ manually.
Try restarting your PC
If nothing helps, try reinstalling PostgreSQL (pgAdmin 4) from the scratch.

answered Mar 30, 2021 at 12:18

NirmalNirmal

571 silver badge8 bronze badges

Go to C:Program FilesPostgreSQL13data, edit postgresql.conf with notepad.

Change:

#port = 54XX

To:

port = 54XX

(change requires restart)

restart service at «service system» on window.

Tony Joseph

1,7922 gold badges14 silver badges17 bronze badges

answered Apr 20, 2021 at 17:54

Using psql with single quotes fails:

psql -c 'Select version();' 'postgresql://username:password@db.abcdefghi.ap-southeast-2.rds.amazonaws.com:8080/the_db'

psql: could not connect to server: Connection refused
(0x0000274D/10061)
Is the server running on host «localhost» (::1) and accepting
TCP/IP connections on port 5432? could not connect to server: Connection refused (0x0000274D/10061)
Is the server running on host «localhost» (127.0.0.1) and accepting
TCP/IP connections on port 5432?

Using double quotes works:

psql -c "Select version();" "postgresql://username:password@db.abcdefghi.ap-southeast-2.rds.amazonaws.com:8080/the_db"

PostgreSQL 10.14 on x86_64-pc-linux-gnu, compiled by x86_64-unknown-linux-gnu-gcc (GCC) 4.9.4, 64-bit
(1 row)

answered Jul 14, 2021 at 1:40

Jeremy ThompsonJeremy Thompson

61.4k33 gold badges188 silver badges318 bronze badges

After a wasting 3-4 hrs i find the solution something like this

First set path in enviroment variable.And then make port and psql connecting same i.e 5432 or 5433

answered Sep 18, 2021 at 3:21

If you newly installed the pgAdmin, and you did not remember to install PostgreSQL at that time, you get that error. Make sure you install both pgAdmin And PostgreSQL.

answered Jan 6, 2022 at 11:14

And so for the new arrivals. If you are using pgAdmin and a Windows operating system, do some research to resolve the issue.

Make sure you have Postgresql installed or active

To do this, go to windows services (press Cmd + R and run the services.msc command)
Look in the list for a service called postgresql-x{BIT}-{Version}-PostgreSQL Server {Version}

Solution 1: If you don’t find the service, then PostgreSQL is not installed or has been uninstalled, install it again.

Solution 2: If you find the service, but you still can’t log in, then most likely the service is not active for some reason, select the service and click the Start or Restart button

answered Mar 24, 2022 at 4:41

emrdevemrdev

2,1153 gold badges9 silver badges15 bronze badges

cd "C:Program FilesPostgreSQL14bin"
pg_ctl -D "C:Program FilesPostgreSQL14data" start

answered Apr 13, 2022 at 6:42

DINA TAKLITDINA TAKLIT

6,82110 gold badges69 silver badges73 bronze badges

If you are a Mac OS user, run these below two commands on termial,

rm /usr/local/var/postgres/postmaster.pid
brew services restart postgresql

answered Mar 16 at 10:30

Источник

Исправить ошибку при открытии файла PostgreSQL ONLINE

Исправляйте, обсуждайте и решайте проблемы, связанные с повреждением базы данных PostgreSQL, в режиме онлайн

Решения для бизнеса

Если использование онлайн сервиса для восстановления невозможно, вы можете скачать одну из следующих утилит:

Recovery for PostgreSQL

Пакеты утилит OfficeRecovery 2012

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

Видео-руководство по использованию сервиса OfficeRecovery Online

“After a hard disk crash we recovered the database from the HD. But it did not run. Recovery for PostgreSQL has restored our data and the table structure. That’s really great. Triggers and constraints were unfortunately lost.

Your tool is great. It has solved our main problem in this case.”

Bernd L.

Методы восстановления PostgreSQL

Сервис по восстановлению поврежденных файлов PostgreSQL анализирует каждый параграф поврежденной базы данных postgresql и восстанавливает все доступные данные с помощью высококачественных низкоуровневых алгоритмов.

Все доступные данные сохраняются в набор SQL скриптов, который и является результатом восстановления.

Не требуется никаких специальных навыков или средств. Просто загрузите поврежденный PostgreSQL файл и дождитесь окончания процесса восстановления. Вы можете получить полностью восстановленную базу данных postgresql, выбрав платные либо бесплатные опции.

OfficeRecovery Online Исправление и Ремонт Файлов PostgreSQL

Для начала важно определить поврежден ли ваш postgresql файл. Файл postgresql поврежден, когда в нём есть несоответствия, которые делают его невозможным для открытия с помощью PostgreSQL. Если во время открытия вашего postgresql файла появилось сообщение об ошибке, или приложение упало, или файл открывается как набор случайных символов, то все это типичные признаки повреждения вашего файла postgresql.

Хорошие новости заключаются в том, что более половины повреждённых файлов postgresql утрачены не полностью. И OfficeRecovery Online for PostgreSQL был создан именно для того, чтобы исправить и починить оставшиеся неповрежденными данные из ваших postgresql файлов. Вы вернете свои данные и сможете открыть файл в PostgreSQL без всяких ошибок.

Вам не нужно скачивать десятки программ для исправления вашего файла. Выберите поврежденный файл postgresql, нажмите на «Безопасная загрузка и восстановление» и дождитесь пока файл будет исправлен. Рекомендуется всегда просматривать бесплатный демо набор SQL скриптов, который доступен после ремонта.

Описание восстановления файла инструментом OfficeRecovery for PostgreSQL Online

Поврежденные базы данных postgresql — это файлы, которые неожиданно стали непригодными для использования и не могут быть открыты с помощью PostgreSQL. Существует ряд причин, по которым файл postgresql может быть испорчен. И в некоторых случаях возможно исправить и восстановить поврежденный PostgreSQL 8.3, 8.2 файл.

Если ваш postgresql база данных внезапно стала поврежденной или недоступной для открытия в программе, в которой она был создана, не отчаивайтесь! Вам не нужно больше покупать дорогое программное обеспечение, чтобы восстановить только один испорченный файл postgresql. OfficeRecovery for PostgreSQL Online представляет вам новый онлайн сервис, который поможет вам восстановить поврежденную базу данных postgresql мгновенно. Все, что вам нужно сделать, это просто загрузить поврежденный postgresql файл, используя браузер, оценить качество восстановления демо результатов и выбрать подходящий для вас вариант решения проблемы.

OfficeRecovery Online for PostgreSQL поддерживает PostgreSQL 8.3, 8.2.
Восстановленные данные сохраняются в набор SQL скриптов, который можно использовать для воссоздания базы данных PostgreSQL.

OfficeRecovery for PostgreSQL Online предлагает бесплатные и платные опции для получения полных результатов восстановления. Бесплатный вариант предполагает, что полные результаты могут быть получены абсолютно бесплатно в течение 14-28 дней. Всё, что вам нужно сделать, это просто подписаться на бесплатные результаты после окончания процесса восстановления файла postgresql. Если же вам нужно получить восстановленный postgresql файл сразу, мгновенно, вам нужно выбрать платный вариант вместо бесплатного.

Что же делать, если в вашем файле postgresql не выявлено данных для восстановления? Вы можете заказать невозмещаемый анализ вашего файла нашей опытной технической командой. В некоторых случаях восстановление данных возможно только вручную.

Вопросы и ответы по Recovery for PostgreSQL

В:	Может ли Recovery for PostgreSQL восстановить мою базу данных PostgreSQL?
О:	Эффективный способ выяснить, подлежит ли восстановлению база данных PostgreSQL — это попробовать на ней демо версию Recovery for PostgreSQL, используя форму для загрузки на этой странице.

В:

Какие ограничения есть у демо версии Recovery for PostgreSQL?

О:

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

Никаких дополнительных строк или таблиц, или других элементов и свойств исходной базы данных не будет восстановлено в полных результатах, если они отсутствуют в демо результатах.

В:	Я пробовал демо. Как мне решить, стоит ли покупать полные результаты восстановления?
О:	Оценка демо результатов может помочь в принятии решения.

В:

Почему в результатах восстановления меньше данных, чем в исходной базе данных PostgreSQL?

О:

Это нормально. Поврежденные части вашей базы данных PostgreSQL будут сконвертированы с нулевым размером на выходе. Другая распространенная причина уменьшения размера файла может быть в том, что некоторые свойства исходной базы данных не поддерживаются и поэтому отсутствуют в восстановленной базе данных.
База данных, восстановленная демо версией, меньше потому, что она в основном состоит из демо-заполнителей, нежели из исходных данных.

В:

После запуска Recovery for PostgreSQL на поврежденной базе данных, были созданы папка с sql скриптом(скриптами) и командный файл. Как эти файлы могут быть преобразованы в новую базу данных?

О:

Чтобы пересоздать базу данных, обработайте полученные sql скрипты, начиная с schema.sql следуйте по dataNNNN.sql. База данных будет пересоздана с нуля.

Для того чтобы сделать процедуру импорта более удобной для конечного пользователя автоматически создается командный файл и сохраняется в папку с sql скриптом(скриптами).

Источник

Ошибки

psql command not found

ERROR: character with byte sequence 0xd0 0x9a in encoding «UTF8» has no equivalent in encoding «WIN1252»

ERROR: database «db» is being accessed by other users

FATAL password authentication failed for user postgres

ERROR: could not open file «/home/user…» for reading: Permission denied

ERROR: COPY quote must be a single one-byte character

ERROR: date/time field value out of range

psql: could not connect to server: No such file or directory

pg_basebackup: could not connect to server: could not connect to server: No route to host

Failed to stop postgresql.service: Unit postgresql.service not loaded

ERROR: WAL level not sufficient for making an online backup

NOTICE: WAL archiving is not enabled

19.3.1.Сбои при запуске сервера

19.3.2.Проблемы с подключением клиента

PostgreSQL 15.0

Содержание

Ошибка: Возникла ошибка при попытке загрузки данных из базы данных. Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment].

Ошибка: Error deleting service при попытке удаления postgreSQL

Принудительно изменить порт используемый программой АРМ ЭРС

Доступ в PGAdmin

Резервное копирование базы данных

Как восстановить базу данных из Бекапа?

Ошибка 1С «Сервер баз данных не обнаружен»

Could not translate host name «NAME» to address: Temporary failure in name resolution

ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident)

ВАЖНО: в pg_hba.conf нет записи для компьютера «», пользователя «usr1cv8», базы «template»

Is the server running on host and accepting TCP/IP connections on port 5432?

«Породить новый процесс для соединения не удалось: Ресурс временно недоступен» или «ВАЖНО: извините, уже слишком много клиентов»

FATAL: database «base» does not exist

Подготовка к восстановлению

Проверка файловой системы

Попытка 1: zero_damaged_pages

Попытка 2: reindex

Попытка 3: SELECT, LIMIT, OFFSET

Попытка 4: снять дамп в текстовом виде

Попытка 5: SELECT, FROM, WHERE id=

Попытка 6: SELECT, FROM, WHERE id >= and id <

Счастливый финал

Благодарности и заключение

Исправить ошибку при открытии файла PostgreSQL ONLINE

Исправляйте, обсуждайте и решайте проблемы, связанные с повреждением базы данных PostgreSQL, в режиме онлайн

Описание восстановления файла инструментом OfficeRecovery for PostgreSQL Online

Вопросы и ответы по Recovery for PostgreSQL

ERROR: character with byte sequence 0xd0 0x9a in encoding «UTF8»

has no equivalent in encoding «WIN1252»

PostgreSQL

15.0