Feedback-ID: i76984098:Fastmail
Message-ID: <53980e64-4bac-44bb-8156-6f5e3fb27d27@aklaver.com>
Date: Wed, 2 Oct 2024 11:23:14 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pg_dump 17 produces files incompatible with older server versions
To: Sam Kidman <sam@fresho.com>, pgsql-general@lists.postgresql.org
References: <CA+FDo=vj+MPhROnDF1b6R=dPrgXeLGUaFbHu=YnHEz7LocSu4A@mail.gmail.com>
Content-Language: en-US
From: Adrian Klaver <adrian.klaver@aklaver.com>
In-Reply-To: <CA+FDo=vj+MPhROnDF1b6R=dPrgXeLGUaFbHu=YnHEz7LocSu4A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/53980e64-4bac-44bb-8156-6f5e3fb27d27%40aklaver.com>
Precedence: bulk

On 10/1/24 22:23, Sam Kidman wrote:
> Hello
> 
> We're developing a rails application and part of our development
> workflow involves dumping out the database schema using pg_dump, which
> is restored whenever we drop and create our development database.
> 
> As of version 17 we now have SET transaction_timeout = 0 in the schema file.
> 
> Unfortunately we use the latest version of the client tools (ie
> pg_dump and kin) but we run the same database server version as we use
> in production (12) and so now we're unable to import our database
> schema with the error below:

https://www.postgresql.org/docs/current/app-pgdump.html

"Also, it is not guaranteed that pg_dump's output can be loaded into a 
server of an older major version — not even if the dump was taken from a 
server of that version. Loading a dump file into an older server may 
require manual editing of the dump file to remove syntax not understood 
by the older server. "

Use the Postgres 12 version of pg_dump to dump if you want to restore to 
Postgres 12 instance.

> 
> ERROR:  unrecognized configuration parameter "transaction_timeout"

Did the above actually stop the restore?

> 
> It might be easier for us if we could configure pg_dump to _not_
> output setting runtime parameters - they're not that important for the
> use case of applying a schema to a database for local development.
> 
> Are there any other solutions to this issue? It could be quite
> troublesome for us as we have a few different postgres server versions
> in use in different applications but we use the same set of client
> tools for all of them.
> 
> Best,
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com