> On 6 Nov 2018, at 09:19, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > > On Wed, Oct 10, 2018 at 9:27 AM Daniel Gustafsson <dan...@yesql.se > <mailto:dan...@yesql.se>> wrote: >>> On 9 Oct 2018, at 16:22, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Daniel Gustafsson <dan...@yesql.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
pg_upgrade_sockdir-v3.patch
Description: Binary data
