Postgres13.7 fail to start with bdr3.7.16 - postgresql

I've installed, postgres13.7 with bdr 3.7.16, below the packages installed:
postgresql13-13.7r2ndq1.1.9-1.el7.x86_64
postgresql13-docs-13.7r2ndq1.1.9-1.el7.x86_64
postgresql13-bdr-3.7.16-1.el7.x86_64
postgresql13-server-13.7r2ndq1.1.9-1.el7.x86_64
postgresql13-libs-13.7r2ndq1.1.9-1.el7.x86_64
postgresql13-devel-13.7r2ndq1.1.9-1.el7.x86_64
postgresql13-pglogical-3.7.16-1.el7.x86_64
postgresql13-contrib-13.7r2ndq1.1.9-1.el7.x86_64
on file 'postgres.conf', I've added:
shared_preload_libraries = 'pglogical,bdr' # (change requires restart)
But if I try to start the node, I receive this error:
waiting for server to start....2022-07-12 14:37:42.934 CEST [1782] FATAL: incompatible library "/usr/pgsql-13/lib/pglogical.so": magic block mismatch
2022-07-12 14:37:42.934 CEST [1782] DETAIL: Server has FUNC_MAX_ARGS = 250, library has 100.
2022-07-12 14:37:42.934 CEST [1782] LOG: database system is shut down
stopped waiting
pg_ctl: could not start server
Which version of pglogical I need to install?
Thanks a lot

Related

PostgreSQL not starting in time

I have restored a backup from psql server A to psql server B. When the postgresql service starts on server B, the log below is produced. From what I read the invalid record length message is not a problem, just an indicator that the end of the last WAL file was reached.
However, when I attempt to run 'psql' it gives a fatal error that the database is starting up. (I waited over an hour and still in that state). I still can't run psql. Note that standby.signal file is present on B, in case that matters.
What does this mean, and how do I fix it? Or is this normal while the standby.signal file is present?
2022-10-18 16:50:47.953 EDT [126144] LOG: starting PostgreSQL 13.5 (Debian 13.5-0+deb11u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2022-10-18 16:50:47.954 EDT [126144] LOG: listening on IPv6 address "::1", port 5432
2022-10-18 16:50:47.954 EDT [126144] LOG: listening on IPv4 address "127.0.0.1", port 5432
2022-10-18 16:50:47.955 EDT [126144] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2022-10-18 16:50:47.963 EDT [126145] LOG: database system was shut down in recovery at 2022-10-18 16:50:47 EDT
2022-10-18 16:50:48.052 EDT [126145] LOG: entering standby mode
2022-10-18 16:50:48.142 EDT [126145] LOG: redo starts at 0/70000028
2022-10-18 16:50:48.142 EDT [126145] LOG: invalid record length at 0/700000D8: wanted 24, got 0
pg_ctl: server did not start in time
2022-10-18 16:52:16.600 EDT [126876] postgres#postgres FATAL: the database system is starting up

PSQL TimescaleDB, ERROR: the database system is in recovery mode

We have an application pipeline and Postgres-12(TimescaleDB, managed through Patroni) on a separate server (VM with Ubuntu 18.04 LTS).
We are facing an issue with the DB, it suddenly stuck in the recovery mode, and also we can’t access it from the psql client and select queries also hung.
After an hour or late all got back to normal (As my current pipeline terminated) and able to run queries against the DB server.
Master DB error details:
2020-11-03 18:35:08.612 IST [9773] [unknown]#[unknown] LOG: connection received: host=x.x.x.x port=58780
2020-11-03 18:35:08.612 IST [9773] FATAL: the database system is in recovery mode
2020-11-03 18:35:08.596 IST [18276] LOG: could not send data to client: Broken pipe
Replica server error details:
2020-11-03 18:34:55 IST [18316]: [85649-1] user=postgres,db=postgres,app=[unknown],client=x.x.x.x LOG: duration: 10.228 ms statement: SELECT * FROM pg_stat_bgwriter;
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
2020-11-03 18:35:08 IST [18322]: [2-1] user=,db=,app=,client= FATAL: could not receive data from WAL stream: SSL SYSCALL error: EOF detected
2020-11-03 18:35:08 IST [20500]: [1-1] user=,db=,app=,client= FATAL: could not connect to the primary server: FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
Pipeline error details:
Job aborted due to stage failure: Task 4 in stage 0.0 failed 3 times, most recent failure: Lost task 4.2 in stage 0.0 (TID 29, ip-x-x-x-x.ap-southeast-1.compute.internal, executor 19): org.postgresql.util.PSQLException: FATAL: the database system is in recovery mode at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:514) at org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:141) at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:192) at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:49) at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:195) at org.postgresql.Driver.makeConnection(Driver.java:454) at org.postgresql.Driver.connect(Driver.java:256) at org.apache.spark.sql.execution.datasources.jdbc.DriverWrapper.connect(DriverWrapper.scala:45)
Please any advise on this issue?
What version of TimescaleDB are you running? In particular, there were some issues with 1.7.x if you try to query a read replica; we recommend upgrading to 1.7.4.
(Otherwise, there's not much information about to suggest what might have happened.)
https://github.com/timescale/timescaledb/releases/tag/1.7.4

PostgreSQL connection issue after service restart

I have edited my pg_hba file and copied it to server and restarted the services by "sudo service postgresql restart" but after that the server is not connecting.
Showing the below error, Your database returned: "Connection to 138.2xx.1xx.xx:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections."
The Jenkins job and data visualization tools are failing which was working fine previously. What could be the reason.
Getting this in PostgreSQL Log
2019-10-23 07:21:25.829 CEST [11761] LOG: received fast shutdown request
2019-10-23 07:21:25.829 CEST [11761] LOG: aborting any active transactions
2019-10-23 07:21:25.829 CEST [11766] LOG: autovacuum launcher shutting down
2019-10-23 07:21:25.832 CEST [11763] LOG: shutting down
2019-10-23 07:21:25.919 CEST [11761] LOG: database system is shut down
2019-10-23 07:21:27.068 CEST [22633] LOG: database system was shut down at 2019-10-23 07:21:25 CEST
2019-10-23 07:21:27.073 CEST [22633] LOG: MultiXact member wraparound protections are now enabled
2019-10-23 07:21:27.075 CEST [22631] LOG: database system is ready to accept connections
2019-10-23 07:21:27.075 CEST [22637] LOG: autovacuum launcher started
2019-10-23 07:21:27.390 CEST [22639] [unknown]#[unknown] LOG: incomplete startup packet
Below shows no response.
root#Ubuntu-1604-xenial-64-minimal ~ # pg_isready -h localhost -p 5432
localhost:5432 - no response
Below was already added to the postgresql.config file.
listen_addresses = '*'
Do i need to restart the entire server?
Can anyone please help me to resolve this.

Change PostgreSQL data directory to directory created by PostgresSQL on another machine

I have a database stored on an external hard drive. The database was created using PostgreSQL 11, on an Ubuntu 18.04 machine. The folder it's stored in was the data directory of my PostgreSQL instance on my Ubuntu machine, everything worked fine. I don't have access to this Ubuntu machine anymore, and this will last for a few months, but I have the external drive. I'm working under macOS 14.6 in the meantime. I setup PostgreSQL on my Mac using the Postgres.app. I created a new server, making sure to use version 11. The defaut data directory was of course not the one I want, so I changed its path in postgresql.conf to point to my existing data dir:
data_directory = 'path_to_external_HDD_data_directory'
Note that this is all I changed in the .conf file (should I change anything else?). When I try to connect to the server via Postgres.app, I get the following error:
pg_ctl: server did not start in time
And the log is:
2019-10-21 22:06:47.628 CEST [72547] LOG: listening on IPv6 address "::1", port 5432
2019-10-21 22:06:47.629 CEST [72547] LOG: listening on IPv4 address "127.0.0.1", port 5432
2019-10-21 22:06:47.654 CEST [72547] LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
2019-10-21 22:06:47.742 CEST [72548] LOG: database system was interrupted; last known up at 2019-10-21 22:00:07 CEST
2019-10-21 22:06:58.263 CEST [72548] LOG: database system was not properly shut down; automatic recovery in progress
2019-10-21 22:06:58.266 CEST [72548] LOG: redo starts at 4A/B2804E40
2019-10-21 22:06:58.266 CEST [72548] LOG: invalid record length at 4A/B2804E78: wanted 24, got 0
2019-10-21 22:06:58.266 CEST [72548] LOG: redo done at 4A/B2804E40
2019-10-21 22:06:58.314 CEST [72547] LOG: database system is ready to accept connections
Postgres.app then tells me that the port is in use. Running lsof -n -i4TCP:5432, I see that postgres is listening. I killed it and retried but got the same pg_ctl error. Any idea of what I can do?
Your server started successfully. You don't use pg_ctl to connect to PostgreSQL, but the command line client psql.
Anyway, you should stop what you are doing right now before any damage is done.
It is not supported to use a PostgreSQL data directory created with one architecture (Linux) on a different architecture (MacOS).
If the server starts, it is by coincidence. Connecting might work, but it might just as well corrupt your database.

Restore postgres db from folder

i have an old copy of my postgresql db folder (/var/lib/postgresql/9.5/main/) from my server. Now I want to get the data out of the files. So i copied the main folder to my local machine and changed the postgresql config (/etc/postgresql/9.5/main/postgresql.conf) to point to that directory. Also i changed the permission of the main directory to the user postgres. After restarting the postgresql service (sudo service postgresql restart) it doesn't really work.
What I'm doing wrong? (Yea I know, pg_dump is the preferred way, but in this way...)
So my question, does this even work?
Or is there a other way to get the data out of this?
everything is done on ubuntu 16.04.
Edit:
the log file after changing the postgresql.conf file to point to the new directory.
2017-10-13 06:15:43 CEST [968-1] LOG: database system was shut down at 2017-10-13 00:21:04 CEST
2017-10-13 06:15:43 CEST [968-2] LOG: MultiXact member wraparound protections are now enabled
2017-10-13 06:15:43 CEST [959-1] LOG: database system is ready to accept connections
2017-10-13 06:15:43 CEST [975-1] LOG: autovacuum launcher started
2017-10-13 06:15:43 CEST [983-1] [unknown]#[unknown] LOG: incomplete startup packet
2017-10-13 06:47:55 CEST [975-2] LOG: autovacuum launcher shutting down
2017-10-13 06:47:55 CEST [959-2] LOG: received smart shutdown request
2017-10-13 06:47:55 CEST [972-1] LOG: shutting down
2017-10-13 06:47:55 CEST [972-2] LOG: database system is shut down
2017-10-13 06:47:55 CEST [4667-1] FATAL: database files are incompatible with server
2017-10-13 06:47:55 CEST [4667-2] DETAIL: The database cluster was initialized without USE_FLOAT8_BYVAL but the server was compiled with USE_FLOAT8_BYVAL.
2017-10-13 06:47:55 CEST [4667-3] HINT: It looks like you need to recompile or initdb.
Ok that pointed me to this. The server is a armv7l, whereas the local machine is x86_64 (uname -m). So there is no chance to get the data out of it?
thx, Luc
If it's really true that your data directory is from an ARM7l system, and your local system is x86_64, you're going to have some difficulties.
The immediate error about USE_FLOAT8_BYVAL is because ARM7L is 32-bit, and cannot pass 64-bit floating point values (8 byte) by-value. Your 64-bit host can. But if you recompiled a custom postgres with USE_FLOAT8_BYVAL disabled you'd likely just run into other issues.
I suggest installing PostgreSQL on a matching ARM system to recover the data. Data directories for PostgreSQL are not portable across architectures (for performance reasons).
If you do not have access to the ARM system anymore, an emulator like qemu should be able to help you.
Otherwise, maybe you can compile a modified PostgreSQL (probably starting with 32-bit x86) that can read the data-dir, with appropriate configure options etc. I've never needed to try this.