Re: Support custom socket directory in pg_upgrade

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Support custom socket directory in pg_upgrade
Date: 2018-11-07 13:21:59
Message-ID: 142EFEA4-99D7-4313-B055-249C4A6F7747@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 6 Nov 2018, at 09:19, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>
> On Wed, Oct 10, 2018 at 9:27 AM Daniel Gustafsson <daniel(at)yesql(dot)se <mailto:daniel(at)yesql(dot)se>> wrote:
>>> On 9 Oct 2018, at 16:22, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>>>> Having hit the maximum socketdir length error a number of times in pg_upgrade,
>>>> especially when running tests in a deep directory hierarchy, I figured it was
>>>> time to see if anyone else has had the same problem? The attached patch is
>>>> what I run with locally to avoid the issue, it adds a --socketdir=PATH option
>>>> to pg_upgrade which overrides the default use of CWD. Is that something that
>>>> could be considered?
>>>
>>> I think you could simplify matters if you installed the CWD default value
>>> during option processing.
>>
>> The attached v2 tries to make the socketdir more like the other configurable
>> directories in pg_upgrade (adding an envvar for it etc). Is that more in line
>> with what you were suggesting? make -C src/bin/pg_upgrade check passes with
>> this, both unmodified and with a -s in the test script to override it. Also
>> fixed incorrect syntax in the docs part from v1.
>
> I think PGSOCKETDIR should be mentioned in the documentation like the
> other environment variables,

Of course, fixed.

> and also I'm wondering if it actually
> works: you set it to the current working directory first, then parse
> the command line option if present, and then read the env var only if
> not already set: but it's always going to be, isn't it? Perhaps you
> should use getcwd() only if all else fails?

Yes, you’re right, I had a thinko in my patch as well as in the testing of it.
The attached version sets cwd as the default in case all else fails. Extending
check_required_directory() to do this may not be to everyones liking, but it
seemed the cleanest option to me.

cheers ./daniel

Attachment Content-Type Size
pg_upgrade_sockdir-v3.patch application/octet-stream 7.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2018-11-07 13:23:10 Re: fix psql \conninfo & \connect when using hostaddr
Previous Message Jesper Pedersen 2018-11-07 13:08:15 valgrind on initdb