Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
От | Andres Freund |
---|---|
Тема | Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set |
Дата | |
Msg-id | 20220213041242.xhpixy3kwwmswkfk@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
|
Список | pgsql-hackers |
Hi, On 2022-01-18 11:20:16 +0900, Michael Paquier wrote: > On Sat, Jan 15, 2022 at 01:52:39PM +0800, Julien Rouhaud wrote: > > libpq environment variable PGHOST has a non-local server value: C:/Users/ContainerAdministrator/AppData/Local/Temp/FhBIlsw6SV > > Failure, exiting > > not ok 3 - run of pg_upgrade for new instance > > There are two things here, as far as I understand: > 1) This is a valid Windows path. So shouldn't we fix pg_upgrade's > server.c to be a bit more compliant with Windows paths? The code > accepts only paths beginning with '/' as local paths, so this breaks. It also doesn't handle @ correctly. Makes sense to fix. Should probably use the same logic that libpq, psql, ... use? if (is_unixsock_path(ch->host)) ch->type = CHT_UNIX_SOCKET; that'd basically be the same amount of code. And easier to understand. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: