Re: multi-install PostgresNode fails with older postgres versions
От | Mark Dilger |
---|---|
Тема | Re: multi-install PostgresNode fails with older postgres versions |
Дата | |
Msg-id | 6B5DD7A9-A0A2-4D60-BF1C-7AD88FE7C539@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: multi-install PostgresNode fails with older postgres versions (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: multi-install PostgresNode fails with older postgres versions
|
Список | pgsql-hackers |
> On Mar 30, 2021, at 3:12 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > On 2021-Mar-30, Mark Dilger wrote: > >> The problem is clear enough; -N/--nosync was added in 9.3, and >> PostgresNode::init is passing -N to initdb unconditionally. I wonder >> if during PostgresNode::new a call should be made to pg_config and the >> version information grep'd out so that version specific options to >> various functions (init, backup, etc) could hinge on the version of >> postgres being used? > > Yeah, I think making it backwards-compatible would be good. Is running > pg_config to obtain the version the best way to do it? I'm not sure -- > what other ways are there? I can't of anything. (Asking the user seems > right out.) Once you have a node running, you can query the version using safe_psql, but that clearly doesn't work soon enough, sincewe need the information prior to running initdb. One of the things I noticed while playing with this new toy (thanks, Andrew!) is that if you pass a completely insane install_path,you don't get any errors. In fact, you get executables and libraries from whatever PATH="/no/such/postgres:$PATH"gets you, probably the executables and libraries of your latest development branch. By forcingget_new_node to call the pg_config of the path you pass in, you'd fix that problem. I didn't do that, mind you, butyou could. I just executed pg_config, which means you'll still get the wrong version owing to the PATH confusion. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: