Readyset always reports 13.4 postgres version, even when using higher postgres

[Object905]

Describe the problem
While trying to use readyset for django 5.2 project (postgres 13 support was removed in this version) I got error django.db.utils.NotSupportedError: PostgreSQL 14 or later is required (found 13.4).

To Reproduce
Run quickstart/compose.postgres.yml. Possibly change postgres version, but 13.4 is reported even on posgres 14

Run psql -d testdb -h 127.0.0.1 -p 5433 -U postgres
That shows psql (17.6, server 13.4 (Readyset)) at the top.

Expected behavior
Upstream postgres version is reported.
There seems to be code that should be doing this, but falls back to DEFAULT_DB_VERSION.

Environment

• Version: docker.io/readysettech/readyset:latest
• Docker
• Postgres 14 and up
• psql, Django

[Object905]

Also I get this error for wagtail pages on postgres 18

Error extending CREATE TABLE, table will not be used error=Failed to manipulate table public.wagtailcore_page: Error during replication: Query failed to parse: nom-sql error: failed to parse query, expected end of input but got: ' DEFERRABLE INIT' (when loading constraints) table=wagtailcore_page

[jasobrown-rs]

Thanks for the report, @Object905, the incorrect version is indeed a bug.

The problem comes as Readyset does not create a connection to the upstream database eagerly when a client connects to it; Readyset instead waits until there's "real work" to do that actually requires the upstream. (You can see this in the LazyUpstream, IIRC). The reasoning behind the lazy connects is that when control plane/operational tools connect to Readyset for health check/diagnostic information, we were inadvertently opening a lot of connections to the upstream postgres itself, and thus naively consuming the limited connections that one can make to PG. Also, if a given client connection will never need to query the upstream anyways, why create that connection?

To fix this, we already have a shared struct with static/global properties of that upstream database (like timezone and schema search path) which we populate at Readyset launch time. I'll just add to that object, and wire it in to the appropriate places.

The other bug you reported is a parsing error, that we'll just need to parse correctly.

[Object905]

@jasobrown-rs
Should I open separate issue for parsing error for wagtailcore_page?
Is \d+ wagtailcore_page in psql enough to debug this?

[jasobrown-rs]

A separate ticket is great, thank you. And, yes, \d+ wagtailcore_page is probably sufficient for the parsing error (also include the error from above). Thanks!

[jasobrown-rs]

I merged a fix for the database version string this morning; it's available in the repo here. It will be included in the next monthly containers build by the end of the month (usually sooner)