pg_dump: error :aborting because of server version mismatch
vangguppie opened this issue · 11 comments
Support guidelines
- I've read the support guidelines
I've found an issue and checked that ...
- ... the documentation does not mention anything about my problem
- ... there are no open or closed issues that are related to my problem
Description
I moved to docker dsmrreader recently with a fresh setup on a raspberry pi 3b+ after having issues with my dsmrreader setup (file system corruption)
Followed the instructions of "run with docker run" and got dsmrreader container(dsmr) working with postgressql in an own container (dsmrdb).
the logfile of the dsmr container is showing a error:
pg_dump: error: aborting because of server version mismatch
pg_dump: detail: server version: 16.0 (Debian 16.0-1.pgdg120+1); pg_dump version: 15.2
2023-10-07 17:29:41,452 ERROR schedule execute_scheduled_processes 39 | (AttributeError) dsmr_backup.services.backup.run errored: 'NoneType' object has no attribute 'read'
Expected behaviour
executing of pgdump command
Actual behaviour
proces not running because of error
Steps to reproduce
- change generate day and hour statitics to a date in the past. (run now)
- error in the log files
Docker info
Client: Docker Engine - Community
Version: 24.0.6
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.11.2
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.21.0
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 3
Running: 3
Paused: 0
Stopped: 0
Images: 3
Server Version: 24.0.6
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 61f9fd88f79f081d64d6fa3bb1a0dc71ec870523
runc version: v1.1.9-0-gccaecfc
init version: de40ad0
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.1.21-v8+
Operating System: Debian GNU/Linux 11 (bullseye)
OSType: linux
Architecture: aarch64
CPUs: 4
Total Memory: 909.6MiB
Name: pi-dock1
ID: 472d520e-baa7-4093-80af-106eb19d8f63
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No memory limit support
WARNING: No swap limit support
Version
- Docker compose version (type
docker-compose --version
): - System info (type
uname -a
):
Docker compose
no docker compose available
Container logs
pg_dump: error: aborting because of server version mismatch
pg_dump: detail: server version: 16.0 (Debian 16.0-1.pgdg120+1); pg_dump version: 15.2
2023-10-07 17:29:41,452 ERROR schedule execute_scheduled_processes 39 | (AttributeError) dsmr_backup.services.backup.run errored: 'NoneType' object has no attribute 'read'
Additional info
No response
Yeah, I've tried to upgrade to the latest client recently, but it gave errors.
Let me try again as some dependencies caused issues.
Hi, late reply, but this should be fixed in the release created Today.
Hi, thank you for your work :-)
Unfortunately, with the latest version (tag 5.10.4-2023.11.01) there is still a mismatch between the server and pg_dump version:
2023-11-24 08:21:23,444 ERROR schedule execute_scheduled_processes 39 | (OSError) dsmr_backup.services.email.run errored: b'pg_dump: error: aborting because of server version mismatch\npg_dump: detail: server version: 16.0; pg_dump version: 15.5\n' pg_dump: error: aborting because of server version mismatch pg_dump: detail: server version: 16.0; pg_dump version: 15.5
I'm using your image on MicroK8s v1.28.3
Kinds regards,
Casper
Hi, thanks! Yes, and unfortunatly I`m dependent on the pg client releases Alpine adds to their release.
In this case (Alpine 3.18), only supports PG up to v15.
https://pkgs.alpinelinux.org/packages?name=postgresql*-client&branch=v3.18&repo=&arch=&maintainer=
However, it seems that you have some knowledge regarding this topic (based on MicroK8s usage). You could try to build your own image based on the Edge image of Alpine. If wanted, I'm happy to help. Before releasing I often use podman to build locally.The biggest challange with Alpine are the dependencies, also in regards to Python. Anyway, nothing that can't be solved :).
Ofcourse another option would be to switch to PG15 server. EOL date is still 3 years from now, and compatibility with other tools and products is still better compared to PG16.
Hi, thank you for your suggestions. I've decided to take the easy route and downgraded postgres to 15.5-alpine3.18 which resolves the issue. I didn't pay attention to the pg16 release date and didn't notice it was still bleeding edge (at least from the alpine point of view). I recognize the alpine dependency troubles, so I chose the easy way out :-)
Thanks again.
Kind regards,
Casper
Great! I believe you've made the best choice. It would have been different if PG15 would be EOL soon. PG16 is just there for a couple of months, so better wait for a bit to migrate indeed.
I ran into the same issue. Will perform a downgrade of PG as well.
@xirixiz May I suggest to put this limitation in the Technologies section of the README.md?
I recently built a new environment myself and did check the README. Didn't see any limitations so went with the latest version of PG only then to find out about the pg_dump version mismatch.
But there is ... https://github.com/xirixiz/dsmr-reader-docker#technologies
Maybe I`m able to share a bit more info in the README regarding this topic.
Yeah, what I meant is extending that part a little bit. It shows minimum versions now, like Postgres >= 13.x
But that suggests 16 is also fine. Maybe something like Postgres >= 13.x AND <= 15.x
That could then be updated after successfully testing a new major version in the future.
Oh yeah, you're right hehehe.... it was meant differently. I`ll fix the README. Thanks!
Fixed!